Моделирование, реорганизация и автоматизация бизнес-процессов Калянов Георгий Николаевич доктор технических наук, профессор, зав. лабораторией ИПУ РАН, зав.кафедрой МФТИ

Управление предприятием с использованием ИТ

ИТ и ИС В современных условиях под информационной технологией (ИТ) понимается регламентированный бизнес-процесс, поддержанный (полностью или частично) информационной (автоматизированной) системой. В соответствии с ГОСТ Р ИСО/МЭК ТО ИС предназначена для сбора, передачи, обработки, хранения и выдачи информации потребителям и состоит из следующих основных компонентов: программного обеспечения, информационного обеспечения, технических средств, обслуживающего персонала.

Схема управления Система управлени я ИС Процессы предприяти я Процессы управлени я Производственны е процессы ИТ ИС

Особенности ИТ относится к классу организационно-технических систем одновременно является объектом управления и частью управляющей системы в процессе управления предприятием с использованием ИТ участвуют следующие системы: 1.производственная система (в качестве целевого объекта управления); 2.система управления предприятием; 3.ИТ как часть системы управления предприятием; 4.ИС как часть ИТ; 5.система управления ИС.

Определение системы (Волкова В.Н.) S =, где z – совокупность целей, str – совокупность структур, реализующих цели, tech – совокупность технологий, реализующих систему, cond – совокупность условий существования системы.

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

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

ИТ цели ИТ (как части системы управления предприятием) направлены на решение задач управления бизнес-процессами, к реализующим цели структурам относятся процессные регламенты, бизнес-подразделения – пользователи ИТ, подразделения ИТ-службы, осуществляющие поддержку ИТ, в качестве реализующих систему технологий, как правило, рекомендуются эталонные модели управления ИТ-услугами, например, ITIL/ITSM.

Условия существования Условия существования каждой из рассматриваемых систем определяются бизнес-стратегией предприятия (и, естественно, ИТ-стратегией, как ее обязательным компонентом).

Управление предприятием с использованием ИТ Лаборатория ИПУ – методов автоматизации управления организационными системами Кафедра МФТИ Системный анализ и управление в области ИТ Учебник Моделирование, анализ, реорганизация и автоматизация бизнес- процессов, ФиС, Учебник Управление развитием информационных систем, Горячая линия – Телеком, 2008г.

Объекты профессиональной деятельности информационные системы и технологии; архитектуры предприятий и функциональные модели предметной области; функциональные и информационные системные модели; ИТ-процессы; ИТ-проекты.

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

Основные результаты Методология реорганизации бизнес- процессов модель бизнес-процесса метод инжиниринга бизнес-процесса метод тестирования бизнес-процесса метод оценки качества бизнес-процесса Методология управления ИТ-проектами Методология ИТ-консалтинга

Специализация Системный анализ и управление информационными системами МФТИ – факультет информационных бизнес- систем (ФИБС) Направление Системный анализ и управление Квалификация – магистр техники и технологии Состав - Теоретические основы анализа и управления ИС. Архитектурный подход к управлению ИС и ИТ. Управление развитием ИС. Классификация ИС. Методы моделирования ИС. Проектирование ИС. CASE-технологии. Технологии управления данными и знаниями. Процессы управления ИТ-услугами. Стандартизация в ИТ-области.

План Моделирование, реорганизация и автоматизация бизнес-процессов Введение - Бизнес и ИТ, ИТ-консалтинг Моделирование бизнес-процессов (методы, этапы проекта) Реорганизация бизнес-процессов Автоматизация бизнес-процессов Концепция архитектуры предприятия ТОП – методология реорганизации

Бизнес и ИТ

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

Революция в бизнесе – переход к процессному подходу Совокупность различных видов деятельности, в рамках которой "на входе" используются один или более видов ресурсов, и в результате на "выходе" создается продукт, представляющий ценность для потребителя (Хаммер, Чампи). Структурированное конечное множество действий, спроектированных для производства специфической услуги (продукта) для конкретного потребителя или рынка (Давенпорт). Логические серии взаимозависимых действий, которые используют ресурсы предприятия для создания или получения в обозримом или измеримо предсказуемом будущем полезного для заказчика выхода, такого как продукт или услуга (Зиндер). Горизонтальная иерархия внутренних и зависимых между собой функциональных действий, конечной целью которых является выпуск продукции или отдельных ее компонентов (Верников). Связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (вещественный или нематериальный результат человеческого труда: предмет, услуга, научное открытие, идея), представляющий ценность для потребителя. (Калашян, Калянов)

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

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

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

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

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

Характеристики консалтинговых компаний знания и информация - главный и единственный их продукт опыт персонала, приобретаемый годами и десятилетиями при работе над конкретными проектами наличие методологии выполнения консалтинговых проектов независимость объективность

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

Наиболее востребованные направления консалтинг в области налогообложения и юридические услуги аудит, бухгалтерский учёт, отчётность и ревизионная деятельность консалтинг в области управления

Управленческий консалтинг По классификации Европейской федерации ассоциаций консультантов по экономике и управлению (ФЕАКО) - более 100 видов консалтинга Управление - любое целенаправленное воздействие на предприятие, как на систему, приводящее к ее планомерному изменению для достижения максимальной эффективности или создания на ее базе новой системы путем заданной цепи изменений Управленческий консалтинг заключается в предоставлении независимых советов и помощи по вопросам управления, включая определение и оценку проблем и/или возможностей, рекомендации соответствующих мер и помощь в их реализации (ФЕАКО) Многофункциональный и междисциплинарный характер

Виды услуг консалтингового процесса Решение проблем бизнеса посредством современных информационных технологий Стратегия развития предприятия Система управления предприятием Процессная структура предприятия Корпоративная информационно-управляющая система (КИУС)

Стратегия развития предприятия ситуационный анализ (стратегическая позиция, сегменты рынка, позиционный анализ) формирование миссии и стратегических целей разработка корпоративной стратегии и философии бизнес-планирование выявление и моделирование бизнес-процессов разработка стратегии развития информационных технологий

Система управления предприятием финансово-экономический анализ производственно-хозяйственный анализ анализ кадрового потенциала формирование системы финансово- экономических показателей постановка управленческого учета управление качеством управление проектами

Процессная структура предприятия инжиниринг/реинжиниринг процессов реорганизация оргструктуры оптимизация документооборота формирование должностных инструкций и положений о подразделениях реструктуризация ИТ-службы предприятия

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

Три основных этапа консалтингового проекта (оказания услуги) диагностика или выявление проблем (сбор данных и их обработку, определение проблемы) выработка решения (определение диапазона допустимых решений, выбор решения, презентация и согласование решения) внедрение решения (разработка программы внедрения, управление процессом внедрения, оценка результатов проекта)

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

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

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

Пример технологии

Моделирование бизнес- процессов Все модели неправильны. Некоторые модели полезны.

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

Участники процесса моделирования Субъект –инициатор моделирования и/или пользователь его результатов Объект-оригинал – предмет моделирования, т.е. та система, которую хочет создать и/или использовать субъект Модель – образ, отображение оригинала Среда – окружение, в котором находятся и с которым взаимодействуют все участники

Функции моделирования Дескриптивная функция – заключается в том, что за счет абстрагирования модели позволяют достаточно просто объяснить наблюдаемые на практике явления и процессы (ответ на вопрос почему так устроен мир?) Прогностическая функция – отражает возможность предсказывать будущие свойства и состояния моделируемых систем (т.е. ответ на вопрос что будет?) Нормативная функция – заключается в получении ответа на вопрос как должно быть? за счет построения образа, желательного с точки зрения субъекта

Требования, предъявляемые к моделям Ингерентность – достаточная степень согласованности создаваемой модели со средой (при этом не только модель должна приспосабливаться к среде, но и среду необходимо приспосабливать к будущей системе) Простота – модель используется как рабочий инструмент, который должен быть обозрим и понятен, доступен каждому участнику) Адекватность – возможность с помощью модели достичь поставленной цели в соответствии с сформулированными критериями (адекватна=полна+точна+истинна)

ИнфоБизнес, 14, от г. Российская фирма, в которой не описаны бизнес-процессы, теряет около 20% товарооборота (руководитель торгово-производственного холдинга Руссо)

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

Модель – основа для выполнения проектов следующих видов: Разработка стратегии развития ИТ Реорганизация бизнес-процессов Создание системы качества Формирование требований к КИУС Анализ рынка и выбор тиражируемых компонент КИУС Разработка ТЗ на создание и/или внедрение компонент КИУС Создание единой базы знаний по функциям и должностным обязанностям специалистов

Требования к моделированию Контекст процессов, а не отдельных служб и подразделений (процессный подход) Структура всего предприятия с целью дальнейшего развития модели Интеграция функциональной, информационной и, возможно, поведенческой компонент Глубина проработки – до уровня функций/операций каждого должностного лица, до отдельных полей каждого документа

Состав бизнес-модели Бизнес-процессы предприятия, пронизывающие его организационно- штатную структуру в соответствии с последовательностью выполнения их элементов Элементы организационно-штатной структуры, ответственные за выполнение функций/операций Прямые и обратные информационные связи Структура информационных потоков

Основные определения Операция - элементарное (неделимое) действие, выполняемое на одном рабочем месте. Функция – совокупность операций, сгруппированных по определенному признаку. Бизнес-процесс – связанная совокупность функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (вещественный или нематериальный результат человеческого труда: предмет, услуга, научное открытие, идея), представляющий ценность для потребителя.

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

Классификация основные процессы сопутствующие процессы вспомогательные процессы обеспечивающие процессы процессы управления процессы развития

Создание программного обеспечения всегда включает в себя существенные задачи – моделирование сложных концептуальных структур, составляющих абстрактный программный объект, и второстепенные задачи – создание представлений этих абстрактных объектов с помощью языков программирования … Фредерик Брукс

Методы и языки моделирования бизнес- процессов

Методы моделирования структурные объектно-ориентированные специальные

Идеи, лежащие в основе структурных методов черный ящик иерархия графическая нотация

def Структурным анализом принято называть метод исследования системы, которое начинается с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограничением числа элементов на каждом из уровней (обычно от 3 до 6-7); ограниченный контекст, включающий лишь существенные на каждом уровне детали; использование строгих формальных правил записи; последовательное приближение к конечному результату.

Средства структурного системного анализа Иллюстрируют: выполняемые функции отношения между данными динамическое поведение

Средства структурного системного анализа DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарями данных и спецификациями процессов (миниспецификациями) или SADT (IDEF0) - диаграммы ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь" STD (State Transition Diagrams) - диаграммы переходов состояний

Модельные связи

DFD-диаграмма

Спецификация процесса МС: Покупка лотерейных билетов Для каждого клиента выполняется проверка наличия требуемого числа билетов лотереи заполнение приходного кассового ордера (Форма 53) и занесение его в НД ДОКУМЕНТЫ ДНЯ ФИЛИАЛА прием наличных денег и занесение операции в НД БАНКОВСКИЕ ОПЕРАЦИИ (при этом осуществляются проводки: Д-т 54, К-т 207) выдача билетов лотереи

SADT-диаграмма

ERD - диаграмма

Классификация методологий структурного системного анализа по отношению к школам - Software Engineering (SE) и Information Engineering (IE); по порядку построения модели - функционально-ориентированные и информационно-ориентированные; по типу целевых систем - для систем реального времени (СРВ) и для информационных систем (ИС).

Наиболее часто используемые методологии НазваниеЧастота использования ШколаПорядок построения Тип целевых систем Йодан/Де Марко36,5%SEФ-ОИС, СРВ Гейн-Сарсон20,2%SEФ-ОИС, СРВ Константайн10,6%SEФ-ОИС, СРВ Джексон7,7%SEИ-ОИС, СРВ Варнье-Орр5,8%SEИ-ОИС Мартин22,1%IEИ-ОИС SADT3,3%IE1) Ф-О 2) И-О ИС CDM (Oracle)0,5%SEФ-ОИС

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

Сравнительный анализ DFD и SADT адекватность средств рассматриваемой проблеме; согласованность с другими средствами структурного анализа; интеграция с последующими этапами (в частности, с этапом автоматизации бизнес-процесса).

Адекватность SADT – хорошо специфицированные и стандартизованные западные бизнес- процессы, DFD – слабая типизация бизнес- процессов, их стихийное появление и развитие наличие миниспецификаций DFD-процессов позволяет преодолеть логическую незавершенность SADT ограничения SADT (6-7 блоков на диаграмме) ведут к неестественному увеличению модели и в ряде случаев затрудняют ее читабельность и понимаемость

Согласованность и интеграция НазваниеERDSTDСтруктурные карты DFDда SADTслабаянет

Инструментальная поддержка До 10% CASE-средств поддерживают SADT, более 80% - различные нотации DFD (материалы CASE Consulting Group) 3% CASE-средств поддерживают SADT, 94% - различные нотации DFD (данные на основе анализа 167 CASE-пакетов)

Базовые модели ОО-методологии объектная модель, отражающая иерархию классов, связанных общностью структуры и поведения и отражающих специфику атрибутов и операций каждого из них (при этом одной из базовых нотаций объектной модели является диалект ERD); динамическая модель, отражающая временные аспекты и последовательность операций (при этом достаточно часто используется STD); функциональная модель, описывающая потоки данных (с использованием DFD).

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

Пример business-use-case

Специальные методы структурные карты (стандарты ANSI и ISO) схемы Харрингтона (Harrington), демонстрирующие структуру бизнес-процесса схемы процесса, базирующиеся на стандарте ANSI и включающие в себя такие объекты как: операция транспортировка инспекция хранение задержка

Бизнес-моделирование и ARIS Organizational Chart - организационная схема Value Added Chain Diagram – VACD-диаграмма Function Tree - дерево функций extended Event-Driven Process Chain - eEPC- диаграмма Office Process - презентационная диаграмма.

Организационная схема

VACD-диаграмма

Дерево функций

eEPC-диаграмма

Презентационная диаграмма (аналог eEPC-диаграммы)

Выбор методологии моделирования бизнес-процессов Структурный системный анализ и проектирование Объектно-ориентированный анализ и проектирование Специальные методы Функционально-ориентированные Информационно-ориентированные DFD SADT

Мифы Cтруктурный или объектно- ориентированный подход? Первичность функциональной или информационной модели? Функциональная модель – диаграммы потоков данных или IDEF0-диаграммы?

Этапы моделирования

Этапы проекта по моделированию 1.Обучение группы аналитиков предприятия с целью дальнейшего их использования в ИТ- отделе и отделе развития 2.Диагностика предприятия 3.Построение моделей 4.Анализ результатов и формирование предложений о необходимости изменений

Этапы обучения 1.Обучение основам методологии выполнения комплекса работ, связанных с построением и анализом моделей, реорганизацией, формированием и контролем требований к КИС (лекции, изучение инструментария, практические занятия) 2.Аттестация группы аналитиков с выдачей сертификата 3.Участие группы аналитиков в выполнении комплекса работ (передача технологий и методик)

Исходная информация при диагностике Стратегические цели и перспективы развития Организационно-штатная структура предприятия Информация о принятых на предприятии технологиях деятельности Результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена) Предложения сотрудников по усовершенствованию бизнес-процессов предприятия Нормативно-справочная документация Опыт системных аналитиков в части наличия типовых решений

Методы анкетирование сбор документов интервьюирование

Анкетирование адресность размер: 1-2 страницы подпись анкетируемого приложение форм документов

Сбор документов Структурированный альбом форм документов – хороший вспомогательный результат проекта

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

Интервьюирование – у кого? отказник говорун балласт экзотическеая должность мелкая сошка

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

Статистические данные составные данные (итеративные компоненты) элементарные данные (формат, область допустимых значений) потоки данных (скорость, интенсивность) процессы (частота, время выполнения) хранилища данных (количество записей, количество обращений, хронология доступа) внешние объекты (количество пользователей, способы использования системы, географическая распределенность)

Глубина проработки моделей Вид проектаПовторная используемость Степень детализации Стратегия ИТ, концепция создания КИУС референсныеукрупненные Система качествасобственныедетальные Реорганизациясобственныедетальные Проектирование КИУС собственной разработки собственныедетальные Проектирование тиражируемой КИУС референсныедетальные

Принципы структурирования 1)в соответствии с деятельностями и бизнес-процессами предприятия, а не в соответствии с его оргштатной структурой 2)верхний уровень модели должен отражать только контекст системы 3)на втором уровне модели должны быть отражены основные деятельности предприятия и их взаимосвязи 4)каждая из деятельностей, в свою очередь, должна быть детализирована на бизнес-процессы (желательно, единственного уровня) 5)дальнейшая детализация бизнес-процессов осуществляется посредством бизнес-функций (обычно 2- 3 уровня) 6)общее число уровней в модели не должно превышать 6-7 7)необходимо выполнять правило накопителей

Классификация основные процессы сопутствующие процессы вспомогательные процессы обеспечивающие процессы процессы управления процессы развития

ГОК: контекстная диаграмма

Автобаза: диаграмма уровня деятельностей

Ремонт и ТО: диаграмма бизнес-процессов

Ремонт: диаграмма бизнес-функций

Учет ремонта: диаграмма бизнес-функций

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

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

Актуальность проблемы спрос на соответствующие работы в рамках проектов создания КИУС отсутствие серьезного опыта выполнения проектов по реорганизации бизнес- процессов появление суррогатных методологий

def Реорганизация бизнес-процессов - совокупность мероприятий по комплексному совершенствованию системы управления, технологий деятельности и взаимодействий (как внутренних, так и внешних), ориентированных на стратегию развития предприятия.

Зачем заниматься реорганизацией? Устранить узкие места в организации бизнес-процессов Повысить качество работы с клиентами Соответствовать новым условиям работы и требованиям рынка Использовать потенциальные возможности предприятия Обеспечить высокий уровень конкурентоспособности

Сегодня любая компания может оказаться вытесненной из бизнеса, если не сумеет вовремя приспособиться... Бывает, понимание необходимости преобразований приходит слишком поздно. Билл Гейтс, Microsoft

Истинно великая компания охотно отказывается от установившейся практики, которая всегда приносила хорошие результаты, в надежде и расчете на нечто лучшее... М. Хаммер, Д. Чампи Реорганизация корпорации

Подходы к реорганизации BSP (business system plannig) - IBM, Мартин CPI (continuous process improvement) - Деминг TQM (total quality management) – японский вариант CPI CMM (capability maturity model for software) – TQM для ПО BPR (business process reengineering) - Хаммер, Чампи Первый проект по реорганизации был выполнен в середине 20-х годов

Эволюционный и революционный подходы 2 варианта проверки кредитоспособности клиента Автобаза – путевой лист Диспетчерская служба ГОК

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

14 принципов Деминга 1)Постоянное совершенствование товара или услуги 2)Следование новой философии производства 3)Отказ от массового контроля 4)Установление долгосрочных партнерских отношений 5)Постоянное совершенствование системы производства и обслуживания 6)Обучение руководства 7)Функция руководителя – руководство, а не надзор

14 принципов Деминга 8) Устранение страха 9) Разрушение барьеров между подразделениями 10) Отмена лозунгов 11) Отказ от количественных показателей 12) Поддержка профессиональной гордости 13) Поощрение образование и совершенствования 14) Необходимые действия для осуществления изменений

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

BPR – характеристикихороших процессов 1)Несколько работ объединяются в одну 2)Исполнители принимают решение 3)Этапы процесса выполняются в естественном порядке 4)Существуют различные версии процесса 5)Работа выполняется там, где ее целесообразно делать 6)Снижение доли работ по проверке и контролю 7)Минимизация согласований 8)Единственная точка контакта 9)Сочетание централизованных и децентрализованных операций

BPR – причины неудач 1)Попытка зафиксировать существующий процесс 2)Внимание не фокусируется на бизнес-процессе 3)Игнорируется все кроме перепланирования процесса 4)Не принимаются во внимание ценности и убеждения людей 5)Предпочтительность незначительных результатов 6)Жесткие ограничения при постановке задачи 7)Попытки начать BPR снизу 8)Недостаток ресурсов при проведении BPR 9)Попытки провести BPR, чтобы никого не обидеть

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

ТОП - методология реорганизации бизнес-процессов планирование (проектирование) тестирование оценка качества

ТОП методология планирования бизнес- процесса – обеспечивает анализ полного множества вариантов его исполнения методология тестирования бизнес- процесса – обеспечивает обнаружение ошибок на этапе создания методология оценки качества бизнес- процесса – обеспечивает адекватную оценку на основе введенных метрик

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

Состояние дел в области стандартизации Стандарты де-факто: DFD, ERD, STD, сети Петри Семейство IDEF (Integrated Computer Automated Manufacturing Definition): IDEF0, IDEF1, IDEF1X, IDEF2, IDEF3, IDEF4 OMG UML 2.0 (UML Superstructure) Р Рекомендации по стандартизации. Информационные технологии поддержки жизненного цикла изделия. Методология функционального моделирования

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

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

Пример1: комплекс корпоративных стандартов компании, внедряющей ERP-систему технология предпроектных исследований технология организации проектных работ методологии и технологии проектирования бизнес- процессов, их унификации и типизации методы перехода от моделей деятельности «как есть» к моделям «как должно быть» методы перехода от моделей бизнес-процессов к системным моделям их автоматизации методы и средства организации и управления проектами инструментальные средства моделирования и проектирования

Пример2: комплекс корпоративных стандартов проекта по моделированию бизнес-процессов общеинформационный документ по проекту описание языка моделирования описание методики построения моделей описание требований к результату моделирования описание необходимой функциональности инструментария описание отчетных форм и форм анкет

Автоматизация бизнес- процессов

Система (на современном этапе) комплекс, состоящий из процессов, технических и программных средств, устройств и персонала, обладающий возможностью удовлетворять установленным потребностям или целям в процессе функционирования автоматизированная система представляет собой совокупность комплекса средств автоматизации, организационно-методических и технологических документов и специалистов, использующих их в процессе своей профессиональной деятельности (ГОСТ Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Термины и определения)

Информационная система ИС - система, предназначенная для сбора, передачи, обработки, хранения и выдачи информации потребителям и состоящая из следующих основных компонентов: программное обеспечение; информационное обеспечение; технические средства; обслуживающий персонал. ИТ-система - набор информационно- технологических ресурсов, обеспечивающий услуги по одному или нескольким интерфейсам (ГОСТ Р ИСО/МЭК ТО )

Экономические предпосылки создания и использования КИУС обеспечение гибкости рыночно-продуктовой стратегии эффективное взаимодействие с партнерами эффективная работа с клиентами эффективное управление ресурсами и процессами оперативное получение достоверной информации анализ больших информационных объемов

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

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

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

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

Цели создания КИУС автоматизаци я ручного труда замен а существующих на предприятии морально устаревших программных систем (ПС) на функциональность модулей тиражируемой системы, поддерживающей современные технологии управления бизнесом

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

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

Значительное число проектов в отечественной практике создания КИУС завершается неудачно либо имеет тенденцию неограниченного увеличения сроков внедрения при одновременном отсутствии значимых результатов. При этом объяснение причины неудачи является традиционным – предприятие не готово к внедрению. Риторические вопросы: 1)Зачем на этом предприятии работали внедренцы- консультанты, ежедневная оплата услуг которых обходилась предприятию в круглую сумму? 2)Почему, получив в итоге за сотни тысяч и миллионы долларов дырку от бублика, предприятия не пытаются вернуть свои деньги, в лучшем случае лишь прерывая контракт?

Приоритетность предприятия над ИТ аудит соответствия уже имеющихся на предприятии информационных систем целям и задачам бизнеса; разработка концепции создания КИУС; выявление, формирование и анализ требований к КИУС; выбор компонент КИУС, наиболее полно удовлетворяющих этим требованиям.

1. Аудит соответствия существующих информационных систем целям и задачам бизнеса общая характеристика объекта аудита техническая оценка по каждой из анализируемых систем

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

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

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

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

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

Основные этапы построения КИУС Определение целей проекта Подготовка к созданию КИУС Выбор поставщиков компонент КИУС Создание КИУС

Определение целей проекта анализ опыта похожих предприятий по созданию КИУС определение целей проекта в контексте системы управления формирование критериев успешности проекта формирование финансового плана

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

Реорганизация Создание КИУС никогда не принесет предприятию должного эффекта без проведения комплекса работ по реорганизации его бизнес- процессов. Внедрение КИУС без реорганизации автоматизируемых БП – не что иное, как возможность более эффективно делать неправильные вещи, в результате такого внедрения возникает среда, автоматизирующая устаревшие процессы и технологии.

Выбор поставщиков компонент КИУС формирование требований к поставщику организация презентаций поставщиков выбор поставщиков определение форм сотрудничества и заключение контрактов с поставщиками

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

3. Анализ требований к КИУС и разработка ТЗ на систему Цели: достижение взаимопонимания между всеми участниками разработки относительно функций и характеристик КИУС; обеспечение возможности видения и корректировки будущей системы до того, как она будет реализована физически; уменьшение затрат на разработку и внедрение системы; обеспечение базиса для планирования, оценки стоимости и времени создания системы.

def Системное проектирование (по другому, моделирование требований к будущей системе) является первой фазой разработки собственно системы автоматизации (именно, фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются Что должна делать будущая система?

Критичные этапы жизненного цикла КИУС Главная особенность индустрии КИУС - концентрация сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов Анализ требований - первая фаза разработки, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?" Этап проектирования - дает ответ на вопрос: "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?"

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

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

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

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

4. Выбор наиболее подходящих программных решений типовые (тиражируемые) компоненты предметные компоненты

Типовые компоненты системы управления предприятиями (MRP-II - Manufactory Resource Planning / ERP – Enterprise Resource Planning) системы управления активами и фондами (EAM - Enterprise Asset Management) системы управления взаимоотношениями с клиентами (CRM – Customer Relations Management) системы управления цепочками поставок (SCM – Supply Chain Management) информационно-аналитические системы (ИАС) системы расчета зарплаты и учета кадров и др.

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

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

Соображения по выбору ПО 1)Обозначение границ реализации 2)Выбор подходящих технических средств 3)Анализ и выбор компонент тиражируемой системы 4)Заказная разработка

Обозначение границ реализации Основные типы реализации: 1)ручная 2)пакетная 3)диалоговая 4)реального времени

Основные варианты выбора компонент КИУС заказная или тиражируемая отечественная или зарубежная весовая категория – от локальных до крупных интегрированных и/или их отдельных модулей.

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

Заказная или тиражируемая? ПараметрЗаказная разработкаТиражируемое решение СтоимостьСопоставима с соответствующим тиражируемым решением Варьируется в зависимости от класса решения и требуемого набора модулей Временные затраты Сотни и тысячи человеко-летМаксимум полгода на выбор, до двух лет на внедрение РаботоспособностьВ первый год эксплуатации число ошибок превышает уровень терпимости пользователя Апробация на ряде предприятий РасширяемостьНизкая за счет дополнительных разработок Высокая за счет приобретения дополнительной функциональности МетодологияВ основе – конкретные процессы конкретного предприятия В основе – лучшие методологии менеджмента

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

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

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

Отечественная ситуация Значительное число проектов в отечественной практике создания КИУС завершается неудачно либо имеет тенденцию неограниченного увеличения сроков внедрения при одновременном отсутствии значимых результатов. При этом объяснение причины неудачи является традиционным (и очень удобным для консультантов-внедренцев) – предприятие не готово к внедрению.

Причины неудач (1) Фактически не система настраивается под предварительно реорганизованные бизнес-процессы конкретного предприятия, а наоборот, предприятие перестраивается под систему (любимая фраза внедренцев - мы проводим реинжиниринг под нашу систему). При этом зачастую и сам выбор системы осуществляется не на основании детальных функциональных требований к соответствующей компоненте КИУС, а попросту навязывается поставщиком. В одном из последних бюллетеней MIT Sloan Management Review отмечается – от 30 до 75% систем не соответствуют ожиданиям пользователей, главная причина – стремление подогнать бизнес- процессы предприятия под существующую технологическую инфраструктуру. Для человека с молотком все выглядит как гвоздь

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

Причины неудач (3) Фактически настройки осуществляются членами проектной группы самого предприятия (бухгалтерами, экономистами, плановиками и т.п.), прошедшими короткое обучение – консультанты лишь отвечают на их конкретные вопросы и решают вставшие перед ними проблемы.