Проблемы внедрения ИС способы их решения (Проблемы анализа и описания бизнес-процессов)

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

• обзор литературных источников, посвященных внедрению КИС;
• анализ типовых проблем реализации ERP-систем на уровне приложений;
• рассмотрение альтернативных решений для выявленных проблем.

1. Обзор проблем внедрения в литературных источниках

Процесс внедрения КИС достаточно продолжителен, поэтому есть смысл разделить его на этапы. Перечень типовых этапов имплементации ERP-систем (рис.1), полученный на основе анализа [1-3], приводится в работе [5]. Рассмотрим активности каждого из этапов, что в свою очередь позволит очертить круг проблем при реализации КИС.

Рис. 1. Типовые этапы внедрения ERP-систем 

На этапе подготовки определяется объем проекта и ведется его планирование. Данные активности управления проектом, поэтому двигаемся дальше. Фаза проектирования является основной и включает анализ требований и процессов заказчика, по результатам которого готовятся проектные решения и список доработок системы. Как выявить и наглядно описать процессы заказчика? В работах [1-3] ответы на подобные вопросы и соответствующие рекомендации не содержатся. На основе описанных процессов совершенствуется система, как следствие возникает потребность в детализации требований в спецификациях на разработку, а также проверке качества программ на этапе реализации. Каким требованиям должна удовлетворять разрабатываемая программа? На что нужно обратить внимание в процессе тестирования? Краткий ответ дается в [2], но лишь на последний вопрос. 

После реализации системы следует фаза подготовки к опытной / опытно-промышленной эксплуатации. Возникает потребность в скором обучении пользователей работе с ней. Сопутствующие проблемы очевидны: недостаточный уровень компьютерной грамотности и чрезмерное число пользователей. Но в [1-3] об этом не сказано ни слова. Дополняет «букет» задача миграции, заключающаяся в трансформации и переносе данных из предыдущих систем в ERP, причем так, чтобы они в любой момент времени совпадали. Во избежание возможной паники рассмотрим перечисленные проблемы подробнее (рис.2). 

Рис. 2. Проблемные области внедрения ERP-систем 

2. Проблемы анализа и описания бизнес-процессов

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

Проблемы несвязности возникают по причине того, что каждый сотрудник ответственен за выполнение лишь заданных операций в рамках интегрированного бизнес-процесса, тем самым общее представление о процессе теряется. Объяснение любой операции требует моделирования процесса, а это время, силы, нервы, куда проще сказать пару общих фраз, поэтому не удивляйтесь скупости описания. И, наконец, одна и та же операция, выполняемая несколькими людьми, определенно будет обрастать совершенно выразительными отличиями, однако верный подход улаживает указанный конфликт безо всяких затруднений. Для разрешения проблем несвязности и ограниченности информации воспользуемся теоремой Шеннона [7]: чем больше разнородной информации, тем достовернее суждение. Следовательно, необходимо использовать информацию из различных источников для полноценного описания процессов (рис.3). При возникновении противоречий целесообразно обратиться к владельцу бизнес-процесса, тем самым будет принято единственное решение из совокупности возможных. Выявленные процессы подлежат описанию и дальнейшему согласованию в документах функционально-технических требований и проектных решений [5]. Ответственные сотрудники подтверждают корректность описания бизнес-процессов, что служит неоспоримым основанием для реализации ERP-системы. 

Рис. 3. Способы проведения анализа бизнес-процессов

Проанализировав требования и выявив бизнес-процессы клиента, переходим к их описанию. Наглядность моделирования бизнес-процессов обеспечивается применением моделей «AS IS» и «TO BE», позволяющих описывать процессы фактические и предполагаемые после внедрения КИС [8]. Существует большое число стандартов проектирования бизнес-процессов [9-11], но какой использовать в том или ином случае? Не найдя прямого ответа на вопрос, выясним, чем же чреват выбор «некорректной» модели. Тип проектирования определяет трудозатраты, читабельность и глубину описания процессов, в результате влияя на продолжительность работ. Любой бизнес-процесс подлежит декомпозиции с последующим моделированием на верхних и нижних уровнях с использованием компонентов описания (операции, условия, ресурсы, входные данные и др.). Рассмотрев работы [8, 12, 13], посвященные анализу и применению наиболее известных способов моделирования бизнес-процессов, разделим стандарты проектирования на три группы: на основе потока работ и данных, а также моделей управления. 

Первая группа способов, включающая диаграммы потока работ (Work Flow Diagram, WFD), действий (Unified Modeling Language – Activity Diagram, UML AD), плавательных дорожек (Swim Lane Diagram, SLD), структурного представления (Integration Definition, IDEF3) и цепочек событий (Architecture of Integrated Information Systems – Extended Event Driven Process Chain, ARIS eEPC), позволяет моделировать различные бизнес-процессы предприятия на нижних уровнях описания. Подобное возможно благодаря применению таких элементов, как решения, условия, И/ИЛИ операторы. Налицо постепенное усиление простейшей нотации описании (WFD) сначала элементами ответственности (UML AD), затем составляющими входных и выходных данных (SLD) и, наконец, временной зависимостью и событиями (IDEF3, ARIS eEPC). Область применения CASE-средств [10] данной группы обширна: от экспресс-анализа до проектирования КИС, в последнем случае чаще всего применяются нотации SLD и ARIS eEPC.

Таблица 1. Реализация требований стандартами проектирования

 Моделирование процессов на основе стандарта потока данных (Data Flow Diagram, DFD) ведется в нотациях Йордана де Марко и Гейна-Сарсона [14], которые ничем, кроме формы компонентов, не различаются, смысловая нагрузка элементов описания едина. Средствами DFD затруднительно вести моделирование сложных бизнес-процессов по причине отсутствия элементов условий, И/ИЛИ операторов, тем не менее, применение нотаций допустимо для проектирования низкоуровневых процессов. Отличительной особенностью DFD является рассмотрение операций тех бизнес-процессов, которые релевантные с процедурами накопления и обработки данных. Следовательно, CASE-средства второй группы рационально использовать для моделирования жизненного цикла данных / документов, в частности, при интеграции информационных систем. 

Модели управления на основе стандартов IDEF0 и ARIS VAD (Value Added Chain Diagram) составляют третью группу [13]. В стандартах IDEF0 и ARIS VAD, как и в случае DFD, отсутствует компонент условий, что делает их механизмами описания верхнеуровневых процессов. Отличительной особенностью IDEF0 является использование ограничений и применение не более трех-четырех операций для описания любого бизнес-процесса. Указанные стандарты используются при декомпозиции процессов на нижние уровни описания следующим образом: IDEF0 применим для WFD, DFD и IDEF3, а ARIS VAD – UML AD, SLD и ARIS eEPC. Подытожим, выбор модели проектирования зависит от предъявляемых к описанию бизнес-процессов требований (табл.1). Например, в процессе внедрения КИС ключевым вопросом выступает распределение ответственностей, в этом случае наиболее приемлемыми стандартами являются UML AD, SLD, ARIS eEPC, содержащими соответствующие элементы описания.  

3. Проблемы подготовки и тестирования спецификаций на разработку

Описав бизнес-процессы в модели «как есть», проводится Fit/Gap-анализ для выявления соответствий и функциональных дефицитов ERP-системы требованиям (рис.4) [5]. Тем самым формируется информативная база для создания модели «как будет». Функциональные разрывы КИС (отсутствие необходимых бизнес-процессов в ERP) часто требуют дополнительных доработок системы. Последние ведутся на основе спецификаций на разработку (технические задания), содержащих постановку задачи и предполагаемые пути решения [15].

Рис. 4. Графическая интерпретация Fit/Gap-анализа

Основная сложность заключается в том, что, решая частную задачу, требуется разработать программу, применимую для общего случая. Почему? Действует «золотое правило»: программа, реализованная для однократного использования, применяется значительно чаще самого важного приложения. Для разрешения подобной проблемы необходимо воспользоваться типовыми требованиями к программным разработкам (вне зависимости от вида разработок), которые обязательно должны быть отражены в спецификации. Руководствуясь работой [15], выделим следующие принципы: 

• обеспечение проверки полномочий;
• отсутствие констант в логике программы;
• реализация контура обратной связи.

Типовыми ошибками при реализации разработок являются отсутствие проверок полномочий (в результате пользователь может обрабатывать данные всех организационных единиц) и наличие в тексте программы константных переменных (например, конкретные значения пользователей, материалов, кредиторов и др.). Налицо признак того, что консультант заблаговременно не подумал о возможности масштабирования программы. Рекомендации по исправлению подобных ошибок содержатся в статье [16]. 

Рис. 5. Виды и объемы тестирования программных разработок 

Взаимодействие пользователя с программой согласно теории управления осуществляется на основе контура обратной связи [17]. Применительно к ERP суть принципа состоит в следующем: пользователь управляет приложением на основе сведений, получаемых на каждом шаге работы программы. Другими словами, необходимо обеспечить информирование пользователей о статусе работы программы (сообщения об успешном выполнении, о возникновении ошибок и др.), предоставить механизмы проверки (отображение результатов выборки и обработки данных) и отслеживания (пометка созданных / измененных данных для последующей ручной корректировки) результатов. Данные принципы следует закладывать в основу любого технического задания на разработку (программы, формуляры, отчеты, расширения) вне зависимости от постановки задачи. Необходимо абстрагироваться от концепции разработки «временных» программ, которые в продуктивной системе должны запускаться один раз для решения частных задач, ведь на практике все происходит целиком и полностью наоборот. Реализовав требуемый функционал ERP, возникает потребность в его проверке. 

Проверка качества разработанной программы осуществляется путем ее тестирования (рис.5). Вид тестирования определяет объем необходимой проверки. Функциональное тестирование ведется для контроля корректности разработки в общем, интеграционное – для проверки правильности отражения результатов работы программы во взаимозависимых областях системы. И, наконец, регрессионное тестирование используется в том случае, когда разработка может повлиять на реализованный ранее ERP-функционал [2]. Функциональное и интеграционное тестирование может проводиться как бизнес-консультантами, так и пользователями системы, в то время как регрессионное – только техническими специалистами. Основным упущением в процессе тестирования разработки является проверка работы программы не в полном функциональном объеме: 

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

В результате программа отлично работает в тестовой, но не продуктивной среде. Любая разработка может быть представлена обобщенной трехуровневой структурой описания, согласно [16]. Введение подобной структуры (рис.6) позволяет задать порядок тестирования программы: сначала проверяется качество реализации экрана задания начальных данных, далее – алгоритмов селекции на основе начальных ограничений и функций обработки выбранных данных. 

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

Рациональность предложенного порядка тестирования разработки закономерна. Первый шаг – это задание ограничений начальных данных. Если уже на этом шаге допущена ошибка, и, например, разработка не удовлетворяет правилу отсутствия констант в алгоритме программы, есть ли смысл в дальнейшем тестировании? Очевидно, что нет. Более того, исправление ошибок, возникших на данном этапе, с высокой вероятностью повлияет на логику работы программы на последующих шагах. Таким образом, тестирование разработки – важный шаг оценки качества программы. Поверхностное и хаотичное тестирование приводит к тому, что разработка корректно работает лишь в тестовой системе. Последующее использование программы в рамках опытной / опытно-промышленной эксплуатации призвано выявить ошибки. Тем не менее, целесообразно использовать данные близкие к реальным и последовательный подход выполнения проверки.  

4. Проблемы обучения пользователей

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

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

Рис. 7. Подходы к формированию инструкций WFD – процессов

Допустим, материалы для обучения подготовлены. В большинстве случаев преподавание проводится модульно с выделением процессов, выполняемых в рамках заданной должности. Количество слушателей имеет значение. Обучать пользователей, когда их 10, 15 или 20, – это одно. Если же их число превышает, допустим, 100 и они территориально удалены, – совершенно другое. В случае небольшого числа пользователей применяют последовательный подход, когда курс логически разбивается на следующие друг за другом части, в заданный день может рассматриваться только определенная часть курса. Обучение проводится минимальным количеством преподавателей, оборотная сторона медали – увеличение сроков проведения. Применение параллельного подхода к обучению обусловлено большим числом слушателей. Подобно последовательному подходу курсы разделяются на части, однако один и тот же материал в течение дня преподается параллельно нескольким группам. Более того, пользователь за день может посещать разные курсы. Итог, с одной стороны – обучение проводится достаточно быстро, с другой – увеличивается число референтов. 

Рис. 8. Преимущества и недостатки видов обучения пользователей 

Решение указанных проблем требует дополнительного времени, вследствие чего увеличиваются как сроки, так и бюджет проекта. Обойти проблему компьютерной безграмотности практически невозможно, поэтому следует сразу обозначить границы: обучить пользователя ровно тем операциям, которые необходимы для отражения транзакций в ERP. Особенно остро вопрос звучит на предприятиях, где сотрудники большую часть времени заняты физическим трудом, при котором взаимодействие с компьютером сведено к минимуму. Обучение большого числа пользователей требует выработки методики и подразумевает использование всевозможных видов преподавания [19]. Виды обучения, а также их преимущества и недостатки приведены на рисунке выше (рис.8). В заключении хочется отметить, что обучение является одним из ключевых процессов внедрения КИС: неподготовленные пользователи не смогут работать в ERP-системе, тем самым результаты работы предыдущих этапов проекта будут попросту обнулены.  

Заключение

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

В общем случае можно руководствоваться следующими рекомендациями:

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

Следование этим рекомендациям позволит снизить риски, возникающие при внедрении информационных систем и увеличить эффективность деятельности предприятия.

Список Литературы.

1. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc., 1999. – 591 p.
2. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
3. О’Лири Д. ERP системы. – М.: Вершина, 2004. – 260 с.
4. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – c.54-62.
5. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
6. Шеннон К. Работы по теории информации и кибернетики. – М.: Информационная литература, 1963. – 824 с.
7. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
8. Галямина И. Управление процессами. – СПб.: Питер, 2013. – 304 с.
9. Заботина Н.Н. Проектирование информационных систем: учебное пособие. – М.: ИНФРА-М, 2014. – 330 с.
10. Белов В.В., Чистякова В.И. Проектирование информационных систем: учебник. – М.: Академия, 2013. – 352 с.
11. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.268-287.
12. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – c.54-62.
13. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Манн, Иванов и Фербер, 2013. – 544 с.