Подходы и процедуры выбора Корпоративных Информационных Систем
В настоящей статье изложены подходы и описаны процедуры выбора не глобальной многоуровневой Корпоративной Информационной Системы (КИС, EIS - Executive Information System) по автоматизации всех бизнес-процессов и видов хозяйственной деятельности компании, а возможных её элементов, как то средств для документационного обеспечения управления, информац…
Согласен с Леонидом- подход получился системным, и в части обобщения и анализа все ок.
Из практики на крупный проект практически на все этапы, начиная с формирования ТЗ, выбора технологии, решения и лонг-листа потенциальных подрядчиков очень полезно иметь в качестве консультанта IT- компанию с хорошей репутацией и опытом работы с аналогичными проектами. Собственных компетенций внутри IT может не хватать или экспертиза может быть односторонней.
Очень правильный комментарий по поводу необратимости процесса- если что-то не учтено в ТЗ и при его корректировках, решение может быть выбрано неверно, поэтому начальные этапы очень важны. Сталкивался с практикой, что на этапе подготовки бизнес- и функциональных требований топ-менеджмент функций, вовлечённых в процессы, зависящие в текущем моменте или в будущем от работы этого ПО , в определенный период времени уделяет 50-75% своего времени работе вместе с проектной командой над максимально корректным описанием требований и ТЗ. Особенно такой подход хорош для сильно кастомизированного софта и уникальных разработок.
Иногда полезно и второе мнение без привлечения консультантов- когда в команде внутреннего аудита есть специалист с IT- бэкграундом высокого уровня(он себя окупает, если компания в принципе проводит много IT-закупок). Тогда тендерному комитету, который обычно далёк от предметной области , проще понимать необходимость закупки того или иного решения, возможные альтернативы в части технологий, подрядчиков, требований по железу и пр.
Ну и конечно код любого уникального решения должен быть в итоге в собственности компании -заказчика, иначе взаимодействие с разработчиком может принимать впоследствии крайне неприятные формы.
С точки зрения контроля добавлю, что CIO не только контролирует проектного менеджера, а еще и регулярно докладывает статус на Правлении - появление новых требований(комплаенс в том числе), интеграция решения с прочими системами компании, миграция исторических данных(особенно если система финансовая) не только волнуют менеджмент, но и отвлекают существенный внутренний ресурс IT, влияя на все прочие проекты, о чем лучше знать как можно раньше.
Спасибо, Андрей, ценные замечания и комментарии!