Нередки случаи, когда крупные компании с собственным штатом ИТ-специалистов, в попытках определиться с формализацией функциональных бизнес-требований к будущей ИТ-системе, привлекают к работе внешних консультантов. Почему? Потому что приходят к пониманию, что сами, без посторонней помощи, этого сделать не смогут. Ведь в вопросе выбора наиболее подходящей системы крайне важны как независимая экспертиза, так и наличие дорожной карты внедрения. Попробуем разобраться, какие ключевые моменты стоит учесть для формализации требований и как это лучше сделать.
1. Нужна ли ИТ стратегия?
Я убежден в том, что руководство компании должно обладать видением развития информационных технологий на горизонт
Что есть стратегия? В первую очередь это — целевая укрупненная архитектура решений и портфель проектов для достижения поставленных бизнес целей. Важно — это живой документ, который меняется.
2. Делать самим или приглашать кого-то?
Мы последовательные сторонники того, что автор и идеолог ИТ-стратегии — это CIO компании. Привлечение сторонней компании — только помощь, но не замена. Безусловно, все можно сделать силами своей команды, но тут всегда есть риск того, что если раньше в подобных работах не было опыта, то качество может оказаться недостаточным. Я видел ИТ-стратегии, списанные с рекламных буклетов кого-то из вендоров — понятно, что толк от этого нулевой. В то время как контракт с интегратором на разработку ИТ-стратегии позволяет получить быстрый доступ к экспертам разных направлений и сформировать разные сценарии развития ИТ.
Но с другой стороны, мне довелось видеть и очень достойные материалы, подготовленные полностью силами сотрудников компании. Поэтому этот вопрос по большей части упирается в возможность объективной оценки собственных возможностей.
3. Что первично — система или стратегия?
Они взаимосвязаны. Разрабатывать стратегию, не опираясь на то, какого класса системы доступны — интересная работа, но имеющая, скорее, академическую ценность. Если для автоматизации определенных бизнес-процессов уже выбрана какая-то система, то этот факт должен существенным образом учитываться.
Например, вы выбрали SAP ERP. Это значит, что у вас должно быть две интеграционных шины — SAP PI для работы внутри SAP и интеграции и отдельная шина для всей остальной интеграции. Конечно же, не имея SAP, планировать две шины странно. Другой пример — 10 лет назад в России были недоступны SCM-решения, и даже проектировать что-то было бессмысленно, но, с другой стороны, тогда был Excel.
4. Определение ключевых проблем в бизнес-процессах
Сбор информации о наличии проблем и пожеланий к автоматизации являются важнейшим критерием для составления ИТ-стратегии проекта. Как правило, это реализуется путем интервьюирования и анкетирования участников процессов, анализа имеющейся статистики и наблюдения за процессами. Но помимо сбора проблем их важно подтвердить или доказать, что тот или иной момент является ключевой проблемой, а не частным случаем. Это позволит оценить потенциал эффективности будущего проекта и конкретного бизнес-процесса после его автоматизации, рассчитать окупаемость вложений на внедрение того или иного решения. От вашей причастности к сотрудникам компании, либо участникам команды, которая будет реализовывать проект, по весьма понятным причинам нередко страдает объективность выявления проблем. Будучи внутри команды очень сложно оценить процесс со стороны.
5. Формирование портфеля проектов
Эту часть ИТ-стратегии очень часто недооценивают. Нередко развертывание ИТ-решений планируют исходя из удобства ИТ, но не учитывают в полной мере требования бизнеса, аргументируя тем, что если делать не по правилам, то придется «переделывать». Неприятная правда в том, что переделывать придется постоянно. Бизнес-среда настолько сильно и быстро меняется, что разрабатываемая система может устареть еще до того, как ее успели внедрить. Поэтому сейчас фокус и приоритет получают проекты, которые дают понятный ROI, причем быстро. Или переводят качество управления на более высокий уровень.
Например, слияние двух банков потребовало перехода одного из банков на АБС другого, что повлекло за собой примерно годичную заморозку развития систем. Под мощнейшим давлением бизнеса сотрудники из ИТ пошли на «неправильную» архитектуру — они внедрили интеграционную шину и связали в режиме онлайн две АБС. После этого организация приобрела еще несколько банков, их также быстро подключили. Но когда бизнес устоялся, всех постепенно, но «правильно» перевели на единую АБС.
Другой проект — в крупном дистрибьюторе с широкой сетью филиалов и распределительных центров. После запуска в головной организации ERP-системы остро встал вопрос получения управленческой отчетности, но ИТ-команда настаивала прежде перевести все филиалы и дочерние организации с «1С» на единую ERP-систему, и лишь после этого заниматься новым решением для аналитики. В итоге бизнес настоял (и не пожалел) на том, чтобы строить аналитическую систему параллельно с тиражированием ERP-решения на филиалы и делать временные интеграции аналитического хранилища и «доживающих» конфигураций «1С». А переход на единую ERP-систему осуществлялся более постепенно.
Поэтому в каждом отдельном случае «правильное» решение может быть своим. А значит, несмотря на то, своими силами будут определены требования к системе, либо с привлечением внешних консультантов, от наличия стратегии развития корпоративных ИТ существенным образом зависит и успешность реализации будущего проекта.
Автор статьи — директор по бизнес-приложениям компании КРОК.
