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

Подробности

Опубликовано: 16.07.2018 16:43

Автор: Степанов Дмитрий Юрьевич

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

Аннотация: рассмотрены проблемы анализа и описания бизнес-процессов заказчика, подготовки и тестирования спецификаций на разработку, обучения пользователей и перехода к продуктивному использованию корпоративной информационной системы. Проанализированы причины возникновения затруднений при внедрении и предложены альтернативные способы решения данных задач.
Скачать: PDF (версия 1), PDF (версия 2), grebennikon.ru.
Ключевые слова: проблемы внедрения корпоративных информационных систем, проблемы внедрения ИС и способы их решения, проблемы разработки информационных систем, проблемы информационных систем, проблемы информационных технологий, проблемы использования информационных технологий, проблемы внедрения информационных технологий, проблемы внедрения КИС, проблемы внедрения erp-системы на предприятии, основные проблемы внедрения ERP систем на предприятии, основные проблемы внедрения и использования ERP-систем, проблемы внедрения информационных систем.

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

Сосредоточимся на рассмотрении уровня приложений. Общеизвестные методологии внедрения приложений [1-3] содержат описание чрезмерно большого числа операций, активностей и проектных документов, что неминуемо приводит к ситуации, когда «из-за деревьев не видно леса». Зачастую проблемы имплементации КИС явно не формулируются, а меж тем консультанту предлагается решить задачу каким-то способом. Все это приводит к тому, что единственным объяснением принятого решения служит формулировка, что «так было на прошлом проекте», а это чревато негативными последствиями. Выделим проблемы, возникающие в процессе внедрения КИС, объясним причины их возникновения и предложим альтернативные способы решения. Тем самым заложим фундамент разрешения наиболее щекотливых задач, с которыми неизбежна встреча в процессе внедрения систем класса ERP (Enterprise Resource Planning) [4].  

Цель и задачи

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

5. Проблемы перехода к продуктивному использованию системы

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

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

Рис. 9. Этапы миграции данных 

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

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

Результаты и их обсуждение

Подведем итоги анализа проблем внедрения КИС, приведенных на рис.2. Проблемы противоречий, неосведомленности и сокрытия информации сотрудниками в ходе анализа требований и процессов заказчика разрешаются путем обзора управленческой документации, документооборота и проведения опросов (рис.3). Задачи выбора стандарта и глубины описания бизнес-процессов решаются определением показателей системы, которые необходимо контролировать в процессе моделирования (табл.1). В частности, применение нотаций ARIS eEPC и SLD продиктовано необходимостью отражения операций в контексте ответственных сотрудников. Разработка программ, применимых для общего случая решения задачи, требует задания проверок полномочий, отсутствия констант в коде программы и реализации контура обратной связи. Все это в совокупности с проверкой всех компонентов программы, тестированием на реальном объеме информации и рассмотрением всевозможных видов данных, событий и начальных условий позволяет рациональнее подойти к вопросу разработки программ вне зависимости от стоящей задачи. 

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

Перечисленные проблемы не исчерпывают всего пула задач, возникающих при внедрении КИС. В работе делается акцент на то, что знание большего количества информации, чем того требует задача, обеспечивает вариативность в процессе принятия решения. Последнее способствует выработке правильного метода системного мышле¬ния. Статья подготовлена в рамках цикла научных работ МГТУ МИРЭА «Анализ, проектирование и разработка корпоративных информационных систем». Перспективным направлением дальнейших исследований является анализ проблем внедрения КИС на уровне управления проектом: планирование и увеличение функционального объема, согласование проектной документации, дефицит людских ресурсов и другие. 

Литература

1. Mouille C. Accenture Delivery Methods and Tools for SAP. http://accenture.com/SiteCollectionDocuments/PDF/Accenture_Delivery_Methods_and_Tools_for_SAP_Final.pdf
2. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc., 1999. – 591 p.
3. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
4. О’Лири Д. ERP системы. – М.: Вершина, 2004. – 260 с.
5. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – c.54-62.
6. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
7. Шеннон К. Работы по теории информации и кибернетики. – М.: Информационная литература, 1963. – 824 с.
8. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
9. Галямина И. Управление процессами. – СПб.: Питер, 2013. – 304 с.
10. Заботина Н.Н. Проектирование информационных систем: учебное пособие. – М.: ИНФРА-М, 2014. – 330 с.
11. Белов В.В., Чистякова В.И. Проектирование информационных систем: учебник. – М.: Академия, 2013. – 352 с.
12. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.268-287.
13. Степанов Д.Ю. Обзор проектных документов при внедрении корпоративных информационных систем // Вопросы экономических наук. – 2014. – т.70, №6. – c.54-62.
14. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: Манн, Иванов и Фербер, 2013. – 544 с.
15. Калашян А., Калянов Г. Структурные модели бизнеса: DFD-технологии. – М.: Прикладные информационные технологии, 2009. – 256 с.
16. Кнут Д. Искусство программирования. Том 1. Основные алгоритмы / Под ред. Козаченко Ю. – М.: Вильямс, 2010. – 720 с.
17. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.
18. Ким Д.П. Теория автоматического управления: линейные системы. – М.: ФИЗМАТЛИТ, 2003. – 288 с.
19. Педагогика: учебное пособие для бакалавров / Вульфов Б.З. и др. – М.: Юрайт, 2015. – 511 с.
20. Дьяченко В.К. Организационная структура учебного процесса и ее развитие. – М.: Педагогика, 1989. – 159 с.
21. Лодон Д., Лодон К. Управление информационными системами. – СПб.: Питер, 2005. – 910 с.
22. Platten J. The data migration go-live strategy – what is it and why does it matter? // Data Migration Pro Expert Journal, – 2009, March 26. http://datamigrationpro.com/data-migration-articles/2009/3/26/the-data-migration-go-live-strategy-what-is-it-and-why-does.html

Выходные данные

Степанов Д.Ю. Проблемы внедрения корпоративных информационных систем: уровень приложений // Менеджмент сегодня. – 2015. – т.87, №3. – c.180-191. – URL: http://stepanovd.com/science/30-article-2015-1-erpappl.