Цель данной работы заключается в анализе и разрешении типовых проблем, возникающих в процессе внедрения КИС, для обеспечения более эффективного процесса имплементации 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.

Используемый стандарт	Уровень описания
ARIS VAD	Верхний
IDEF0	Верхний
Work Flow Diagram	Нижний
UML Activity Diagram	Нижний
Swim Lane Diagram	Нижний
ARIS eEPC	Нижний
IDEF3	Нижний
Data Flow Diagram	Нижний

---

Таблица 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]. Функциональное и интеграционное тестирование может проводиться как бизнес-консультантами, так и пользователями системы, в то время как регрессионное – только техническими специалистами. Основным упущением в процессе тестирования разработки является проверка работы программы не в полном функциональном объеме: 

---

Смотрите также файлы

• Сравнительный анализ OLTP и Olap-систем (происходит относительно).pdf

• Организация анализа требований к ИС (способность автоматизировать все этапы).pdf

• Согласование результатов оценки: методы и требования (стоимость оцениваемой недвижимости).pdf

• Знания и навыки, необходимые мне для управления собственным бизнесом.pdf

• Civilization Pluses n Wildlife.pdf