CC BY
46СОВРЕМЕННЫЕ ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ ИНТЕГРИРОВАННЫХ СИСТЕМ УПРАВЛЕНИЯ
© Шарипов М.А.*
Ульяновский государственный университет, г. Ульяновск
Разработка метода разрешения задачи проектирования корпоративной информационной системы, предназначенной к внедрению в бизнес-среду компании, послужило целью настоящего исследования. Принципиально новым является использование в работе подходов к построению интегрированной системы управления, инструментарии которых воздействуют на бизнес-процессы предприятия. Наряду с определением задач проектной группы, а затем и внедренческой команды автор приводит соответствующие примеры применения двух различных подходов проектирования корпоративной информационной системы.
Ключевые слова ERP-система, CASE-подход, метод BRP, бизнес-процессы компании.
Компании и предприятия, масштабы экономической деятельности которых принуждают к внедрению корпоративных информационных систем, в первую очередь, сталкиваются с такой фундаментальной задачей, как выбор методологии проектирования и построения корпоративной информационной системы.
Корпоративные информационные системы представляют собой IT-про-дукты категории ERP (Enterprise Resource Planning System - «система планирования ресурсов предприятия»), известные также как «интегрированные системы управления» [2, с. 40]. Каким же образом руководство компаний приходит к вышеприведённой задаче?
Во-первых, ERP-система позволяет оперативно управлять ресурсами предприятия, комплексно охватывая важнейшие бизнес-процессы в едином информационном пространстве и упорядочивая бизнес-процедуры.
Проект по внедрению IT-программы категории ERP, как правило, дорогостоящий (несколько млн. долл.), длительный (от нескольких месяцев до пару лет, включая «обкатку» в тестовом режиме) и влечёт большие убытки и рыночные потери в случае неудачного опыта.
Во-вторых, центральное место в ходе интеграции ERP-системы в уникальную бизнес-среду компании занимают бизнес-процессы, а необходимым условием эффективной работы программы выступает комплексный охват ключевых функциональных областей.
* Аспирант кафедры Финансов и кредита.
Тем самым, учитывая тот факт, что деятельность любого предприятия специфична и содержит в себе ряд конкурентных преимуществ, выраженных в бизнес-процессах, появляется требование заказчика внедрения IT-решения к вендору или интегратору системного продукта об инкорпорировании идиосинкратических бизнес-процессов заказчика в ERP-программу.
Именно в тот момент, когда заказчик начинает строить возможные образы того, как эти конкурентные бизнес-процессы будут позиционироваться в будущей интегрированной системе управления, проектная группа компании-заказчика и становится перед непреложным выбором метода проектирования архитектуры внедряемого бизнес-приложения.
Таков алгоритм поступательного движения руководства и проектной группы компании к этапу фундаментального выбора технологического подхода к проектированию IT-системы.
Решение ответственного руководителя по внедрению программного продукта на предприятии сопровождается с одновременным решением по созданию проектной группы компании, то есть процесс приобретения, возможной разработки и интеграции ERP-системы в бизнес-среду организации приобретает проектный статус. В свою очередь, проектная группа до начала процедуры поиска и выбора подходящего разработчика или интегратора программного решения должна понимать, что на единой информационной платформе должны быть автоматизированы сферы, увязанные между собой в деятельности предприятия. Несмотря на то, что связанные области весьма различны по отраслям, требуется чтобы ERP-система покрывала половину или более бизнес-процессов компании. Эффективность от внедрения IT-про-дукта категории ERP будет выше и быстрее достижима при условии полного охвата нескольких смежных зон деятельности компании с поддержкой сквозных бизнес-процессов.
В итоге задачи проектной группы сводятся к следующим. Главная и первая из них есть мониторинг бизнес-среды компании на наличие конкурентных и уникальных бизнес-процессов, которые дают неоспоримые рыночные преимущества. Исходя из результатов мониторинга, группа должна прийти к решению: выбрать к внедрению базовые модули ERP-системы при отсутствии ключевых бизнес-процессов или модифицировать интегрируемый программный продукт под выявленные уникальные бизнес-процессы. В первом случае проектной группе остаётся лишь выбрать поставщика ERP-системы после разработки проекта построения корпоративной информационной системы. Сам поставщик может выступать в лице вендора или интегратора. Когда поставщик-вендор, внедрением занимается сам разработчик программного продукта (SAP, ORACLE), но существуют такие вендоры, как например Microsoft и 1С, делегирующие услуги по внедрению партнёрам-интеграторам.
Внедрять немодифицированные базовые модули ERP-системы предприятиям, лишённым уникальных бизнес-процессов, позволяет отличительная
особенность ERP-системы как программного продукта - обкатка на многих тысячах внедрений во всём мире [1]. Таким образом, покупая программный продукт у вендоров или интеграторов, компании получают и мировой опыт интеграции IT-решений в бизнес-среду компании для различного рода отраслей, содержащих в себе лучшие практики управления.
Но при обнаружении ключевых бизнес-процессов у проектной группы появляются новые задачи, среди которых и заявленная в начале работы -выбор методологии проектирования и построения корпоративной информационной системы.
Как было подмечено выше разрешение данной задачи имеет фундаментальное значение, но возможны два варианта развития. Представляется, что первым вариантом является выбор методов построения корпоративной информационной системы за счёт собственных ресурсов (проектная группа, отдельно информационная служба компании) или приобретения консалтинговых IT-услуг, второй - совместно с поставщиком ERP-системы. Последний вариант более приемлем постольку, поскольку сами вендоры являются активными пользователями различных методов проектирования и построения архитектуры при разработке своих программных продуктов.
Стоит отметить тот факт, что при инкорпорировании конкурентных бизнес-процессов компании в ERP-систему целесообразно формировать внедренческую команду в составе из представителей заказчика и разработчика (или интегратора). Данный этап представляет собой отличную возможность для совместного разрешения задач сначала разработки подхода к проектированию корпоративной информационной системы, затем - интеграции ключевых бизнес-процессов в ERP-программу и дальнейшего внедрения IT-ре-шения в компании, включая и функционирование в опытном режиме. Помимо руководителя службы IT заказчик также должен быть обязательно представлен и высшим менеджментом.
Оптимальным распределением усилий в деятельности внедренческой команды представляется вариант, когда сторона заказчика проецирует свои уникальные бизнес-процессы на информационную платформу будущей интегрированной системы управления с использованием подобного опыта вендора, то есть проектирует образ ERP-системы (видение своей производственной «IT-площадки», удобной и понятной для пользования), а исполнитель непосредственно занимается позиционированием бизнес-процессов в программном продукте, видоизменяя архитектуру IT-решения.
Остановимся на основных подходах к проектированию и построению ERP-продукта.
CASE (Computer Aided Software Engineering) - первый из них. Данная методология устроена посредством инструментальных средств, которые служат для автоматизации построения системы. Подход CASE содержит в себе два направления: проектирование бизнес-задач и создание на их базе плат-
формы будущей системы. CASE состоит из таких важных модулей, как объекты бизнес-среды, исполняемые с их помощью процессы, события, изменяющие объекты и сами процессы. CASE-метод минимизирует зависимость бизнес-моделей от IT-технологий, что позволяет дополнять программу согласно изменениям в конкурентных бизнес-процессах компании.
CASE-метод отличается моделированием взаимосвязей между сущностями. Моделирование: событийное, функциональное и информационное. Поэтому данный подход подразумевает активное применение специального рода диаграмм Entity-Relationship, то есть «сущность-связь».
Сам процесс моделирования базируется на строгих соглашениях и стандартах, которые, в свою очередь, ликвидируют неопределённость и поддерживают диалог с конечным пользователем. Ключевые требования CASE-подхода следующие.
Во-первых, отношение к информации как к главному ресурсу организации. Во-вторых, наличие административной поддержки в целях адекватного формулирования принципов, предъявляемых к информации. В-третьих, использование строгих стандартов и соглашений в рамках нормализации данных. Также CASE-метод требует: краткого описания понятий в модели и их однозначного отражения, независимости данных, настраиваемых шаблонов в целях ускорения и упрощения процедуры обработки данных.
В итоге процесс проектирования ERP-системы по методу CASE начинается с выработки стратегии (построения схем потока данных, самих взаимосвязей между сущностями и функциональной иерархии). Далее следует этап анализа, что включает в себя детализацию схем предыдущего этапа и логики функций, построение комплексной схемы иерархии функций и диаграммы перехода различных состояний. Завершает процесс этап разработки, подразумевающий сетевую архитектуру, прогнозную оценку масштаба базы данных и проецирование сущностей, функций и модулей.
Стоит отметить, что сущность в условиях CASE-подхода есть важное явление или же объект, информация о которых подлежит запоминанию или выяснению.
CASE-метод является многопользовательским, ориентированным на групповое использование, а в сочетании с интерактивными построителями диаграмм и схем вкупе с возможностью формирования отчётов повышает качество проектирования ERP-программы и производительность внедренческой команды.
Альтернативой вышеприведённому подходу выступает система реинжиниринга бизнес-процессов (Business Process Reengineering - BRP) - наиболее «агрессивный» подход в отношении уникальных бизнес-процессов компании, потому как заключает в себе инкорпорацию IT-технологий в деловые процессы предприятия как их неотъемлемую часть, что, в свою очередь, приводит к переструктуризации и переосмыслению конкурентных
бизнес-процессов компании. Иными словами в отличие от предыдущего подхода воздействию подвергаются уникальные бизнес-процессы компании, которых придётся встраивать в ERP-продукт. Тем самым может показаться, что при использовании данного метода внедренческая команда занимается лишь интеграцией бизнес-процессов заказчика в модульный вариант ERP-системы вендора или же интегратора, несмотря на то, что интеграция именно программы категории ERP в бизнес-среду заказчика есть главная задача команды. Описанное представление в корне ошибочно постольку, поскольку сама деятельность команды по внедрению ERP-системы предполагает активное воздействие на интегрируемую систему и её изменение, а потому на самом деле в случае применения именно BRP-подхода внедренческой команде предстоит комплексное воздействие как на IT-продукт, так и на бизнес-процессы заказчика, обусловливающие его конкурентные преимущества.
В итоге становится очевидным, что компания, применяющая метод BRP, должна быть неким «конструктором», отличающимся определённой степенью гибкости. И рекомендовать BRP-подход стоит только тем предприятиям, у которых запланировано расширение производства и наличествуют весомые противоречия в организационной структуре, разрешить которых, в свою очередь, возможно при переосмыслении уникальных бизнес-процессов компании.
Реинжиниринг бизнес-процессов содержит в себе всего четыре этапа. Первый этап подразумевает разработку модели будущей компании, второй - анализ существующих конкурентных бизнес-процессов компании, а третий этап заключается в изменении бизнес-процессов или разработке нового их образа. Интеграция нового проекта в бизнес-среду компании завершает процедуру реинжиниринга уникальных бизнес-процессов на предприятии. Проведение этапов может быть непоследовательным, параллельным и многократным.
Одновременное воздействие на интегрируемый IT-продукт и на собственные конкурентные бизнес-процессы влечёт большие риски в части конкурентных рыночных преимуществ, утрата которых весьма вероятна при непропорциональном изменений бизнес-процессов. В связи с этим при выборе подхода BRP внедренческая команда должна осознавать тот факт, что непременными условиями применения реинжиниринга выступают интеграция IT-решения категории ERP последнего поколения и воля к воздействию на конкурентные бизнес-процессы компании.
Исходя из сравнения методов CASE и BRP, стоит сделать вывод, что при наиболее ценных уникальных бизнес-процессах следует применить подход CASE, позволяющий проектировать будущую интегрированную систему управления, учитывая особенности конкурентных бизнес-процессов и подстраивая систему под них. Осмелиться же на использование BRP-метода разумно при запланированном расширении предприятия, проблемной орга-
низационной структуре и недетализированных конкурентных бизнес-процессах. Внедренческая команда в этом случае должна отличаться высоким профессионализмом, а роль исполнителя целесообразно отдать непосредственно вендору, потому как воздействие на бизнес-процессы дело сложное, и влекущее огромные рыночные риски.
Список литературы:
1. Кудрявцев А. Планирование на основе характеристик и Make-to-Order сценарий в SAP APO [Электронный ресурс] - Режим доступа: www.erp.ru/ planirovanie-na-osnove-xarakteristik-i-make-to-order-scenarij-v-sap-apo.html (дата обращения: 04.02.13).
2. Ходырев А. Курс на обгон // Эксперт. - 2009. - № 35. - С. 40-46.
3. Barker R. CASE*Method: Entity Relationship Modelling. - Wokingham, England: Addison-Wesley, 1990.
4. Barker R. CASE*Method: Tasks and Deliverables. - Wokingham, England: Addison-Wesley, 1991.
5. Carrol B. Lean Performance ERP Project Management: Implementing the Virtual Supply. - Florida, USA: CRC Press, 2012.
