Как разработать концепцию по смене платформы ИС? Инструкция к применению

В середине 2000-х при выборе платформы ИС большинство производителей продуктов питания остановились на 1С УПП. И за последние 10-15 лет построили и, можно сказать, «вросли в нее корнями» (будь то чистое 1С УПП или отраслевое решение на его основе). Кто-то старался активно развивать все в одной информационной базе, кто-то разделять функционал подразделений в разные базы. Но, как ни крути, УПП была и остается центральным элементом выстроенной системы, т.к. консолидирует в себе все транзакции финансово-хозяйственной деятельности предприятия.

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

Вопрос: на что переходить? Стандартный ответ: конечно на 1С:ERP. Но здесь надо понимать, что, когда компании начинали развивать свою систему на базе УПП, масштаб, скорость развития и степень автоматизации бизнеса были совсем другими, а уровень ИТ-кадров вообще практически никакой. Когда-то автоматизации бухучета всем казалось достаточно. Сейчас ИС стали действительно важным элементом поддержки бизнес-процессов, а в бизнесе появились люди, которые отвечают за ИТ профессионально. И они осознают, что ИТ-система – это не просто программка, которую можно поменять с одной на другую (как например, мобильный телефон, переставив сим карту) и решить этим все свои проблемы. Смена платформы – это совсем из другой оперы.
При этом даже грамотный ИТ-специалист не всегда знает, как перейти с платформы А на платформу В. Особенно если известно только «А» (и то не всегда :)), при том, что целевое состояние «В» пока находится в тумане.

Вот откуда возникает потребность в разработке концепции развития ИС.

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

ПОСЛЕДОВАТЕЛЬНОСТЬ ШАГОВ

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

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

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

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


«ПОДЫТОГ» 1
Мы только что перешагнули экватор и теперь знаем не только «от чего мы уходим» но и «что должно быть результатом» смены платформы ИС.

Мы определили:

• какие информационные базы нам необходимы
• на каких продуктах они будут созданы
• какие задачи в каких базах будут решены
• какой информацией эти базы будут обмениваться между собой

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

4. Разделение задач на набор проектов
Практика показывает, что в рамках разработки концепции для среднего/крупного пищевого предприятия у нас появляется от 50 до 100 ИТ-задач, которые должны быть решены. В один присест такое количество задач не решить. Концепция разрабатывается на горизонт 3-4 года. Поэтому мы делим эти задачи на набор проектов. По опыту, для перехода в целевое состояние 100 задач можно скомпоновать в 10-20 проектов.

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

5. Построение план-графика выполнения проектов по вехам и формирование бюджета проекта
По каждому проекту необходимо оценить:

• ресурсоемкость
• приоритетность (исходя из потребностей бизнеса)
• взаимозависимость проектов (некоторые проекты просто невозможно сделать раньше других исходя из технологической зависимости)
• оценка стоимости привлечения проектных исполнителей

«ПОДЫТОГ» 2
Теперь мы знаем не только «какая она, точка В», но и как в нее добраться и сколько времени и денег понадобится на переход. Надо понимать, что адекватные ответы на эти вопросы мы можем получить, только пройдя все шаги именно в вышеуказанной последовательности, а не торопясь с выводами. Прогнозируемые показатели, которые, разумеется, вам никто не запретит делать на любом этапе, так и останутся прогнозами, так как не будут иметь под собой никаких обоснований. Если, к примеру, рассчитать стоимость на втором шаге, не зная, на каких платформах будут реализованы системы, итоговая стоимость будет сильно отличаться от той, на которую вы надеялись.

6. Определение количества необходимых ИТ-ресурсов
При невысоком уровне автоматизации предприятию достаточно присутствия системного администратора + максимум одного 1С-ника. Однако, как только компания вступает на путь цифровой трансформации бизнеса и сделаете ИТ-систему важным элементом в эффективности и конкурентной борьбе, перед вами открывается вечно зеленое поле задач по ИТ-поддержке. Автоматизация избавляет вас от необходимости мириться с ошибками неквалифицированных кадров, однако сразу появляется необходимость поддержки системы в целевом состоянии. Поэтому здесь мы определяем структуру и количество необходимых для этого ИТ-ресурсов. Часть этих ресурсов компания обязательно должна иметь внутри, часть можно отдать на аутсорсинг.

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