Сейчас, когда появилось и активно развивается решение «1С:ERP» от 1С, многие компании задумываются о смене информационной системы. Повторяется история десятилетней давности.
Когда мы только начинали свой путь, многие переходили «с семерки» на «восьмерку». И очень часто мы слышали такое: «У нас что-то наделано в «семерке» непонятное, сейчас мы начнем все сначала, перейдем на УПП и сделаем все по уму».
Однако, к сожалению, у большинства «по уму» так и не получилось. В результате сейчас мы снова слышим: «Наша УПП такая неуправляемая и сильно кастамизированная, вот перейдем на ERP и тогда…».
Не хочется, чтобы компании снова повторяли свои и чужие ошибки уже на 1С:ERP. Поэтому сегодня поговорим о том, как этого избежать, грамотно управляя жизненным циклом информационной системы.
Что такое жизненный цикл информационной системы (ЖЦИС)
Когда мы начинаем внедрять ИС, например, с решения локальной задачи по продажам или закупкам, мы представляем (в идеале) конечную точку, к которой система в итоге должна прийти. Однако осилить все работы, которые отделяют начало от конечного результата, за один присест (проект) просто нереально.
Поэтому развитие системы обычно происходит этапами – проект (скачок функционала) + время на устаканивание системы, (когда функционал растет чуть медленнее), а затем – новый проект. В идеале система должна развиваться так, как показано на рисунке.
Однако состояние системы, в котором она дойдет до конечной точки (и дойдет ли вообще), зависит от того, как мы управляем всем жизненным циклом этой системы, а не только проектами.
Как же выстроить работу по управлению жизненным циклом системы так, чтобы в итоге достигнуть желаемого результата?
7 составляющих системы управления ЖЦИС
Ведение структурированной документации (сохранение знаний)
Для успешного развития системы компания должна на регулярной основе вести, хранить и своевременно обновлять следующую документацию:
— методологическую (регламенты, которые описывают логику работы системы на уровне бизнеса)
— инструкции по работе с системой (документы, которые содержат информацию о том, как регламенты реализуются в системе)
— организационную (протоколы/приказы по развития системы, которые фиксируют, кто и что делает с системой, планы работ по ее развитию)
Выпуск новых релизов (от требований до обновления рабочей базы) и хранение их истории с описанием изменений
Обычно система развивается так: программист утром встал, почесал голову и решил что-то допилить. Сказано-сделано, а результат добавлен в рабочую базу. Плохо или хорошо то, что он сделал для общего развития системы – не очень понятно. При этом он, скорее всего, не один такой «умный». Обычно оставить свой след в системе находится много желающих. В результате рабочая база развивается стихийно.
По-хорошему, в компании должен быть налажен процесс выпуска релизов, который проходит все стадии тестирования. Причем все релизы должны сохраняться, чтобы вы имели возможность вернуться к предыдущей версии, если что-то пойдет не так.
Описание окружения системы (описание того, как рабочая база взаимодействует с внешним миром)
У компании должны быть документы, где четко прописано:
— где располагается рабочая база (сервера, их адреса)
— пользователи и их роли (должны быть четко описаны)
— способы подключения к рабочей базе (тонкий, толстый клиент, веб и т.д.)
Управление инцидентами пользователей (решение проблем на первой линии поддержки)
Этот пункт подразумевает наличие понятного процесса подачи заявки о проблеме и ее дальнейшего решения.
Управление багами
Если в ходе решения инцидента выявлена реальная ошибка, она должна решаться уже на уровне создания и выпуска нового релиза.
Управление исполнением и распределением задач (управление ресурсами)
У компании должен быть список ресурсов как внутренних, так и внешних, которые можно привлечь со стороны для решения задач по развитию системы. В этом случае любой объем работы можно будет выполнить в установленные сроки, грамотно распределяя его между исполнителями.
FAQ
Список типовых инцидентов и описание их решений, чтобы ускорить процесс решения проблем пользователей.
Все знают, но мало кто делает…
Конечно, описав эти подходы, мы не придумали чего-то нового. Да и зачем изобретать велосипед? Озвученные принципы, как показывает наш опыт, из разряда «must have» для тех компаний, которые хотят развивать свою систему в долгосрочной перспективе, а не получить спустя какое-то время неуправляемое нечто. Помните, как в одном детском стишке:
«Ну, а это что такое,
Непонятное, чудное,
С десятью ногами,
С десятью рогами?»
«Это Бяка-Закаляка, Кусачая,
Я сама из головы её выдумала».
«Что ж ты бросила тетрадь,
Перестала рисовать?»
«Я её боюсь!»
К сожалению, система управления жизненным циклом ИС очень редко встречается на реальных российских предприятиях. Обычно все держится на людях. Чаще всего компании ограничиваются решением инцидентов и багов, просто потому, что их в любом случае надо как-то решать. Это насущная необходимость. Однако даже здесь далеко до полноценного управления, так как чаще всего все заканчивается написанием обычного электронного письма в ИТ-отдел, после которого айтишники начинают бегать (или не начинают, все зависит от серьезности проблемы).
Документированное развитие системы при этом происходит в лучшем случае только во время проекта (это при условии, если компании повезло иметь хорошего подрядчика).
В результате такого подхода картинка развития системы выглядит несколько удручающе.
Какой результат Вы получите, построив систему управления ЖЦИС
Во-первых, Вы обеспечите развитие ИС в долгосрочном периоде и в итоге достигните желаемого состояния, как на первой картинке. Вы сможете сохранить те результаты, которые с таким трудом были получены в ходе проектов внедрения и преумножить их самостоятельно. А значит, Вы получите от системы больше и обеспечите рост ROI (возврат на инвестиции) от ИТ.
Во-вторых, вы станете меньше зависеть от Ваших айтишников. Теперь смена сотрудников не будет приводить к катастрофе масштаба предприятия, так как развитие системы сведется к решению ряда понятных задач, которые смогут выполнить любые квалифицированные специалисты.
И наконец, ваш собственный ИТ-отдел станет гораздо продуктивнее, так как будет обеспечен всем необходимым инструментарием для плодотворной работы.
Успешного вам развития и очень вас прошу, задумайтесь о будущем системы уже на этапе первого проекта, а еще лучше – на этапе его планирования, чтобы через несколько лет система не превратилась в «бяку закаляку» из детского стишка.
