Метод большого взрыва и франчайзинговая стратегия для внедрения и импортозамещения корпоративных информационных систем

Подробности

Опубликовано: 30.09.2023 11:25

Автор: Катасонова Наталья Сергеевна

Просмотров: 858

Аннотация: в работе анализируются стратегии внедрения ERP-систем: большой взрыв, франчайзинговая стратегия и точный бросок. Рассматриваются три практических кейса: внедрение информационной системы для нескольких подразделений, имеющих сквозной бизнес-процесс, имплементация системы ERP на предприятиях холдинга, имеющих схожие процессы, а также импортозамещение программного обеспечения в случае известной/не известной даты отключения. Для каждой задачи доказывается выбор наилучшей стратегия имплементации.
Скачать: PDF (статья), PDF (выпуск №23).
Ключевые слова: метод тестирования большой взрыв, метод большого взрыва, метод франчайзинговой стратегии, метод точного броска, стратегии развертывания, стратегии развертывания приложений, стратегии развертывания системы, способ имплементации по, проект пилотного внедрения, тиражирование проекта, деплой приложения, деплой проекта, деплоймент.

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

Каждая из 3-х стратегий внедрения имеет свою область применения, тем самым дополняя друг друга. Так метод большого взрыва предполагает внедрение корпоративной информационной системы сразу на все предприятия заказчика. Франчайзинговая стратегия, наоборот, подразумевает выделение тестовых подразделений, на которых будет обкатываться программное решение. Лишь позже и после успешной апробации оно будет имплементировано на все оставшиеся предприятия. Третья стратегия, точный бросок, используется для лоскутно-кусочной автоматизации, в рамках которой внедряется лишь часть программного продукта для относительно небольшого бизнес-процесса. Если суммировать стратегии, то получим следующее резюме [2]:

• большой взрыв применим для наискорейшего получения выгоды от программной системы;
• франчайзинговая стратегия подразумевает предварительную обкатку программного продукта и лишь потом его массовое внедрение;
• точный бросок предполагает имплементацию ПО частями, небыстро, но верно.

Рассмотрим три задачи, которые позволят оценить рациональность использования того или иного способа внедрения:

• 1-я задача: компания состоит из одного юридического лица, в состав которого входят 5-ть подразделений. Ключевой сквозной процесс охватывает все пять подразделений, где одно предприятие закупает продукцию для производства, три других производят готовую продукцию, а последнее ее продает. Поэтому между подразделениями ведется передача ТМЦ (товарно-материальных ценностей);
• 2-я задача: предприятие, представленное одним юридическим лицом, состоит из 10-ти подразделений, ведущих схожие бизнес-процессы. Перемещение ТМЦ между подразделениями существует, однако незначительно;
• 3-я задача: в компании используются зарубежные программные продукты различных стандартов: ERP, WMS, TMS, APO, BI и MES. В контексте импортозамещения необходимо перейти на российские аналоги программных решений.

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

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

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

2. Схожие процессы нескольких подразделений и франчайзинговая стратегия

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

Для пилотных подразделений ведутся следующие фазы проекта внедрения:

• анализ;
• проектирование;
• реализация;
• тест;
• переход к опытно промышленной эксплуатации (ОПЭ);
• гиперподдержка ОПЭ;
• переход к промышленной эксплуатации (ПЭ),

в то время, как для тиражирования:

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

Важно, что по результатам фазы ОПЭ принимается решение об успешности пилотного проекта. Если проект признан успешным, то лишь в этом случае следует тиражирование решения на оставшиеся подразделения. Тиражирование имеет следующие особенности:

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

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

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

Поэтому для каждого подразделения необходимо уточнить:

• перечень верхнеуровневых требований, сопоставленных с картой бизнес-процессов 1-3 уровней;
• число конечных пользователей в разрезе карты процессов 1-2 уровней;
• срочность автоматизации;
• критичность в масштабах холдинга.

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

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

Подход к организации проекта тиражирования:

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

Рис. 1. Иллюстрация запуска пилотных подразделений и тиражирование программного решения

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

• анализ;
• проектирование (все подразделения);
• реализация (все подразделения);
• тест (все подразделения);
• переход к ОПЭ;
• гиперподдержка ОПЭ;
• переход к ПЭ,

а этапы тиражирования представимы:

• переход;
• гиперподдержка ПЭ,

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

3. Импортозамещение и метод точного броска

Согласно определению, метод точного броска позволяет автоматизировать ограниченный набор бизнес-процессов. Имплементация корпоративной системы только для целей автоматизации одной или нескольких функций встречается крайне редко, поэтому считаем данный метод нерелевантным. В контексте задачи №3 решается вопрос импортозамещения программного обеспечения, представленного функциональным ядром из систем: ERP, BI и MES, а также прочими классами программных решений, к которым можно отнести EWM, TMS, APO и др. Здесь возможны три подсценария:

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

Рис. 2. Подсценарии импортозамещения: а) срочная замена ПО, дата отключения неизвестна, б) дата отключения ПО известна, в) разнесенная по времени стратегия импортозамещения ПО

Первый подсценарий самый негативный, он фактический превращается в подготовку и исполнение плана обеспечения непрерывности бизнеса (Business Continuity Plan, BCP), призванного описать все задачи и активности, позволяющие предприятию хоть как-то выполнять регулярные бизнес-процессы, даже при отсутствии программной системы. Здесь определяется:

• кто, как и где должен выполнять ручные операции;
• сколько дополнительных FTE (Full Time Employee, новый сотрудник, работающий на 1-у ставку) понадобится;
• как долго и с какими ограничениями компания может проработать в таком режиме;
• какие обязательные мастер и транзакционные данные нужно сохранять вовне ежедневно для целей проекта замещения ПО;
• какие временные локальные программные решения нужно разработать, чтобы упростить ручные операции и др.

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

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

Третий подсценарий менее проблематичный. Здесь нет BCP плана, так как сроки отключения задаются самостоятельно. Последовательность замещения ПО состоит в том, чтобы в первую очередь импортозаместить второстепенные программные системы, только после этого те, что являются функциональным ядром. Выбор систем к замещению ведется в том числе принимая во внимание число интеграционных потоков, пронизывающих конкретное ПО: чем больше интеграционных связей, тем позже будет замещена система (рис. 2В). Основная задача, решаемая в этом подсценарии, обеспечить безболезненный переход на новое программное решение, исключая простои и минимизируя период остановки компании. Поэтому именно в этом случае довольно часто используют параллельную работу в двух системах, что позволяет проверить и сравнить, как работает новая программная система, при необходимости откатиться к применению старого решения (наличие фазы опытно-промышленной эксплуатации). Здесь допускается применение как способа большого взрыва, так и франчайзинговой стратегии.

Подводя итоги стратегиям внедрения корпоративных информационных систем, хочется отметить следующее. Метод большого взрыва применим при имплементации программного решения, оргобъем проекта которого ограничен 3-5 подразделениями или существует сквозной процесс, пронизывающий все подразделения, делающий автоматизацию только части из них бесполезной. Франчайзинговая стратегия релевантна проектам, в объем которых входит большое число подразделений, требует предварительной оценки параметров предприятий для определения состава пилотного проекта и тиражирования. Метод точного броска практически не применим при внедрении КИС. В зависимости от условий, проекты импортозамещения могут реализовываться как по схеме большого взрыва, так и франчайзинговой стратегии.

Литература

1. Олейник П.П. Корпоративные информационные системы: учебник для вузов. – СПб.: Питер, 2012. – 175 с.
2. Першин Д.С. Стратегии внедрения ERP-систем // Корпоративные информационные системы. – 2022. – №4 (20) – С. 1-6. – URL: https://corpinfosys.ru/archive/2022/issue-20/204-2022-20-erpdeploystrategy.

Выходные данные статьи

Катасонова Н.С. Метод большого взрыва и франчайзинговая стратегия для внедрения и импортозамещения корпоративных информационных систем // Корпоративные информационные системы. – 2023. – №3 (23) – С. 1-11. – URL: https://corpinfosys.ru/archive/2023/issue-23/227-2023-23-implementationstrategy. 

Об авторе

Катасонова Наталья Сергеевна – выпускник кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Применение каскадной, итерационной и спиралевидной моделей внедрения информационных систем для автоматизации городской больницы». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №23

1. Agile Feature Driven Development для автоматизации МПЗ (часть 2);
2. Метод большого взрыва и франчайзинговая стратегия;
3. Отличия внедрения SAP и 1С программных решений класса ERP;
4. Цифровой рубль: использование и учет на предприятии.