Не превращайте систему в чудовище или управление жизненным циклом информационной системы

7 минут чтения

884342__wallpaper-scenic-art-official-monsters_p

Сейчас, когда появилось и активно развивается решение «1С:ERP» от 1С, многие компании задумываются о смене информационной системы. Повторяется история десятилетней давности.

Когда мы только начинали свой путь, многие переходили «с семерки» на «восьмерку». И очень часто мы слышали такое: «У нас что-то наделано в «семерке» непонятное, сейчас мы начнем все сначала, перейдем на УПП и сделаем все по уму».

Однако, к сожалению, у большинства «по уму» так и не получилось. В результате  сейчас мы снова слышим: «Наша УПП такая неуправляемая и сильно кастамизированная, вот перейдем на ERP и тогда…».

Не хочется, чтобы компании снова повторяли свои и чужие ошибки уже на 1С:ERP. Поэтому сегодня поговорим о том, как этого избежать, грамотно управляя жизненным циклом информационной системы.

Что такое жизненный цикл информационной системы (ЖЦИС)

Когда мы начинаем внедрять ИС, например, с решения локальной задачи по продажам или закупкам, мы представляем (в идеале) конечную точку, к которой система в итоге  должна прийти. Однако осилить все работы, которые отделяют начало от конечного результата, за один присест (проект) просто нереально.

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

кривые для поста1

Однако состояние системы, в котором она дойдет до конечной точки (и дойдет ли вообще), зависит от того, как мы управляем всем жизненным циклом этой системы, а не только проектами.

Как же выстроить работу по управлению жизненным циклом системы так, чтобы в итоге достигнуть желаемого результата?

7 составляющих системы управления ЖЦИС

  1. Ведение структурированной документации (сохранение знаний)

    Для успешного развития системы компания должна на регулярной основе вести, хранить и своевременно обновлять следующую документацию:

    — методологическую (регламенты, которые описывают  логику работы системы на уровне бизнеса)

    — инструкции по работе с системой (документы, которые содержат информацию о том, как регламенты реализуются в системе)

    — организационную (протоколы/приказы по развития системы, которые фиксируют, кто и что делает с системой, планы работ по ее развитию)

  1. Выпуск новых релизов (от требований до обновления рабочей базы) и хранение их истории с описанием изменений

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

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

  1. Описание окружения системы (описание того, как рабочая база взаимодействует с внешним миром)

    У компании должны быть документы, где четко прописано:

    — где располагается рабочая база (сервера, их адреса)

    — пользователи и их роли (должны быть четко описаны)

    — способы подключения к рабочей базе (тонкий, толстый клиент, веб и т.д.)

  1. Управление инцидентами пользователей (решение проблем на первой линии поддержки)

    Этот пункт подразумевает наличие понятного процесса подачи заявки о проблеме и ее дальнейшего решения.

  1. Управление багами

    Если в ходе решения инцидента выявлена реальная ошибка, она должна решаться уже на уровне создания и выпуска нового релиза.

  1. Управление исполнением и распределением задач (управление ресурсами)

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

  1. FAQ

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

Все знают, но мало кто делает…

Конечно, описав эти подходы, мы не придумали чего-то нового. Да и зачем изобретать велосипед? Озвученные принципы, как показывает наш опыт, из разряда «must have» для тех компаний, которые хотят развивать свою систему в долгосрочной перспективе, а не получить спустя какое-то время неуправляемое нечто. Помните, как в одном детском стишке:

«Ну, а это что такое,
Непонятное, чудное,
С десятью ногами,
С десятью рогами?»

«Это Бяка-Закаляка, Кусачая,
Я сама из головы её выдумала».
«Что ж ты бросила тетрадь,
Перестала рисовать?»
«Я её боюсь!»

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

Документированное развитие системы при этом происходит в лучшем случае только во время проекта (это  при условии, если компании повезло иметь хорошего подрядчика).

В результате такого подхода картинка развития системы выглядит несколько удручающе.

кривые для поста

Какой результат Вы получите, построив систему управления ЖЦИС

Во-первых, Вы обеспечите развитие ИС в долгосрочном периоде и в итоге достигните желаемого состояния, как на первой картинке. Вы сможете сохранить те результаты, которые с таким трудом были получены в ходе проектов внедрения и преумножить их самостоятельно. А значит, Вы получите от системы больше и обеспечите рост ROI (возврат на инвестиции) от ИТ.

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

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

Успешного вам развития и очень вас прошу, задумайтесь о будущем системы уже на этапе первого проекта, а еще лучше – на этапе его планирования, чтобы через несколько лет система не превратилась в «бяку закаляку» из детского стишка.

0 0 votes
Рейтинг статьи
guest
0 Комментарий
Inline Feedbacks
View all comments
Связаться с нами

 

×
Copy link