Комплексные IT-решения для бизнеса
+7 (812) 642-74-62

Управление изменениями в информационной системе

7 шагов к управляемым изменениям в информационной системе

После внедрения в компании корпоративной информационной системы часто  возникает необходимость в доработке внедренного решения. Однако вопросам управления изменениями уделяется недостаточно внимания. Как правило, подразумевается, что задачи по управлению изменениями будет решать штатный программист, а ставить ему задачи будут пользователи.

Зачастую, при такой организации процесса, пользователи вскоре обнаруживают, что система «ведет себя» не так как надо.  В качестве примера «неправильного поведения» можно привести следующие:

  • В корпоративной системе «плодятся» отчеты, повторяющие друг друга,
  • Вы регулярно сталкиваетесь с системными ошибками в рабочей базе,
  • После внесения заказанных Вами изменений перестает работать что-то другое,
  • От своих сотрудников Вы регулярно получаете жалобы на работу системы,

Из-за чего же возникают приведенные выше ситуации, и что мешает их избежать? Чтобы ответить на этот вопрос, необходимо понять, как в идеале должна выглядеть схема взаимодействия заказчика изменений и программиста. Представляется, что необходимо выделять следующие этапы:

1. Выявление потребности

Потребность в изменениях корпоративной системы может возникать из-за изменений  в законодательстве, методах учета или Вы хотите, например, использовать новый отчет.

2. Постановка задачи

На этом этапе происходит формализация потребности - то есть формулируется непосредственно задача для разработчика.

3. Анализ задачи

Если выявить потребность и сформулировать задачу, теоретически, может сам заказчик, то анализ поставленной задачи должен проводиться совместно со специалистом ИТ. Необходимо понять какие изменения внутри системы может повлечь за собой выполнение задачи, принять решение о возможности и способах ее выполнения, оценить трудозатраты, установить срок.

4. Документирование запроса на изменение.

Документальное сопровождение процесса внесения изменений в корпоративную систему – это, например, составление технического задания. В документе фиксируются цели и назначение изменений, сроки выполнения и этапы разработки. Для разработчика этапы разработки - это непосредственный план работ.

5. Разработка.

Собственно, внесение изменений в код. Может выполняться как штатным программистом, так и силами внешних исполнителей.

6. Тестирование и проверка.

Тестирование производится в 2 этапа. На первом этапе тестирование производится ИТ специалистом, на втором – заказчиком. Тестирование выполняется на копии рабочей базы.

7. Доставка изменений в рабочую базу.

Перенос изменений из тестовой базы в рабочую. Производится после подтверждения заказчиком соответствия результатов тестирования запросу на изменение.

Однако на практике обычно происходит по-другому. Зачастую пункты 2, 3, 4 и 6 игнорируются. И происходит это по разным причинам. Очевидно, что у пользователей может быть недостаточно знаний для правильной постановки задачи, а у программиста, перегруженного обработкой заявок, выполнение которых требуется «вчера», физически не хватает времени на полноценный анализ, написание технической документации и контрольное тестирование.

Если заявки пользователей не анализируются и не документируются, то изменения внутри Вашей корпоративной системы становятся бесконтрольными, а это значит, что в разы увеличиваются риски на появление блокирующих ошибок. При этом следует понимать, что чем чаще производятся изменения системы и чем они глобальнее, тем выше риски.

Для того чтобы управлять изменениями в системе, нужен ресурс, с помощью которого будет происходить централизованная постановка задач разработчику. Когда появляется «фильтр» между пользователями и программистом, Вы начинаете планировать изменения в корпоративной системе. На этапе «фильтрации» принимается решение о необходимости предлагаемых изменений и принятым задачам назначается приоритет. Как правило, на практике большая часть обращений пользователей может быть решена без доработок корпоративной системы. В ряде случаев пользователю необходима консультация по работе с системой, а если заявка пользователя подразумевает доработки, то необходимо проанализировать – действительно ли нужны эти изменения или есть альтернативные варианты решения вопроса.  В случае, если доработка система необходима,  то для разработчика должна быть корректно сформулирована и поставлена задача на доработку.

Документируйте вносимые в систему изменения, особенно если они затрагивают общую логику работы. Составление технического задания для разработчика поможет провести более точную предварительную оценку трудозатрат, а  задокументированные этапы разработки – сохранить историю изменений корпоративной системы. Это поможет специалистам ИТ быстрее ориентироваться в ситуации, а следовательно и оперативно устранять ошибки в случае их появления.

Конечно, для качественного управления изменениями корпоративной системы в идеале требуется не один программист или менеджер, а целая команда компетентных специалистов, которая сможет наладить процессы внесения изменений в ИС. Именно поэтому, многие компании выбирают альтернативный вариант – обращаются к внешним подрядчикам.

Очевидно, что затраты на «реанимацию» корпоративной системы многократно превышают затраты на планирование и анализ при внедрении и последующей эксплуатации. При правильно организованном взаимодействии заказчика изменений и компетентного разработчика, Вы получите быстрое и эффективное решение вопросов, а работа корпоративной системы будет надежна и стабильна, как швейцарские часы.

Светлана Аверина