Недавно мы разбирали, как построить UML-диаграмму последовательности на примере проведения платежей в интернет-магазине с помощью защищенного банковского шлюза. В продолжение этого кейса, сегодня построим UML-диаграммы вариантов использования, классов и состояний для системы оплаты курса с применением промокода на скидку.
Границы системы, акторы и варианты использования: что такое диаграмма Use Case
Проектируя программную систему, аналитик прежде всего отвечает на вопрос, что она должна делать, т.е. какие возможности представлять для разных пользователей. Для описания таких вариантов использования в UML есть одноименная диаграмма – Use Case. Она позволяет наглядно показать границы системы и ее функции, сгруппированные по контексту – прецеденты. При том, что каждый прецедент фактически отражает одно или сразу несколько функциональных требований, UML-диаграмма Use Case и одноименная форма представления требований – это разные вещи, хоть и связанные между собой. Подробнее об этом мы рассказывали в отдельной статье.
Эффективно о бизнесе. Описание бизнес-процессов vol.1
В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка.
Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу). Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.
Далее следует детализировать, как именно выполняется процесс оплаты, раскрыв прецедент со схемы Use Case на UML-диаграмме последовательности. Однако, чтобы сделать это с привязкой к внутренним сущностям нашей программной системы, классам, следует сперва описать их на UML-диаграмме классов. Как это сделать, мы рассмотрим далее.
Ликбез по ООП или как построить UML-диаграмму классов
UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации.
Как правильно описать бизнес-процесс?
При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).
Ассоциация означает логическую связь между объектами разных классов. Например, договор на обучение связан с курсом. Поскольку в договоре нужно обязательно указать курс, эти классы будут связаны не простой ассоциацией, а ее более сложным вариантом – агрегацией. В этом случае у класса, который является целым, появится значок в виде незакрашенного ромбика.
Если связь между объектами разных классов настолько сильная, что при уничтожении целого, уничтожаются и его части, ромбик будет закрашенным. Такая связь называется композицией и является самым сильным вариантом ассоциации. Можно также указать кратность связи, к примеру, в 1-м договоре на обучение могут быть указаны сразу несколько курсов. При этом над концами связи отобразятся мультипликаторы, обозначающие ее кратность.
Источник: babok-school.ru
VIII Международная студенческая научная конференция Студенческий научный форум — 2016
Целью данного исследования является формирование методики описания бизнес-процессов с применением Case-технологий, направленных на повышение эффективности управления организацией.
Исходя из поставленной цели, определены следующие задачи:
- выбор инструментального Case-средства для описания бизнес-процесса организации:
- описание бизнес-процесса организации с применением Case-технологий.
Российские ученые В.В.Репин и В.Г.Елиферов [1] дают следующее определение бизнес-процесса — «это устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя».
Вход — ресурс, необходимый для выполнения бизнес-процесса.
Выход — результат выполнения бизнес процесса.
Международный стандарт качества ISO 9000 [2] рекомендует организациям для того, чтобы результативно функционировать, необходимо управлять своими процессами.
А для того, чтобы правильно управлять процессами требуется их изучить и описать.
Первая задача. Выбор инструментального Case-средства для описания бизнес-процесса организации.
Наиболее популярными на рынке Case-средствами моделирования бизнес-процессов являются BPWIN, ARIS, RAMUS.
Для выбора инструментального CASE-средства исходим из критериев:
- функциональность (возможности) CASE-средства;
- простота использования;
- доступность приобретения (цена) CASE-средства.
Значения критериев определили, используя открытые ресурсы в сети Интернет:
Наличие функции моделирования бизнес-процессов
Доступность приобретения (цена)
Требуется специальное обучение
Сравнив CASE-средства для описания бизнес-процесса организации выбрали RAMUS, которое позволяет моделировать бизнес-процесс, распечатать модель, имеет простое использование и есть бесплатная усеченная версия.
Вторая задача. Описание бизнес-процесса организации с применением CASE-технологий.
Моделирование бизнес-процесса — это графическое описание бизнес-процесса с использованием CASE-средства.
В данной работе для описания бизнес-процесса организации использовали методологию структурного анализа и проектирования SADT, разработанную в 1973 году Дугласом Россом, а именно ее подмножество — стандарт IDEF0. В моделях IDEF0 процесс (функция) изображается в виде функционального блока. (Рис. 1)
Каждая из четырех сторон функционального блока имеет свое назначение: левая сторона блока предназначена для Входов, верхняя — для Управления, правая — для Выходов, нижняя — для Механизмов.
Вход — материал или информация, которая используется или преобразуется функцией для получения результата (выхода).
Управление — нормативные документы, инструкции, которыми руководствуется функция.
Выход — материал или информация, которые производятся функцией.
Механизм — ресурсы, которые выполняют функцию, например персонал предприятия, компьютеры. Программное обеспечение.
Моделирование бизнес-процесса выполнили на примере деятельности Министерства сельского хозяйства и продовольственной политики Республики Саха (Якутии):
1. В соответствии с методологией SADT моделирование бизнес-процессов организации начинается с общего представления деятельности организации в виде единственного блока А-0, блока «Деятельность Министерства сельского хозяйства и продовольственной политики» (Рис. 2).
2. На следующем уровне общий блок А-0 детализируется с помощью 3-4 блоков соединенных интерфейсными дугами. Эти блоки определяют основные процессы организации и представлены на диаграмме А0 (Рис. 3).
3. Затем каждый из этих основных процессов может быть декомпозирован подобным образом в целях большей детализации процессов. В данном случае, декомпозировали основной процесс «Участие в реализации федеральных программ. » еще на 3 подпроцесса (Рис. 4).
В заключении хотела сказать, что каждое предприятие для повышения эффективности управления должно применять CASE-технологии по управлению бизнес-процессами.
Для описания бизнес-процессов организации:
- провели сравнение CASE-средств моделирования бизнес-процессов;
- использовали методологию структурного анализа и проектирования SADT;
- изучили деятельность организации, используя ее сайт;
- провели моделирование бизнес-процессов с использованием CASE-средства — программным средством RAMUS.
Список использованной литературы
1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М., Финансы и статистика, 2000. — 544с.
2. Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. — М., РИА Стандарты и качество, 2009. — 544с.
3. Хаммер М., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. — М.: Манн, Иванов и Фербер, 2007. — 288с.
4. Шеер А.В. Бизнес-процессы. Основные понятия. Теория. Методы. — М.: Весть-Мета Технология, 1999. — 144с.
5. ИСО 9000:2005 Системы менеджмента качества. Основные положения и словарь. 3 издание — Компания «Технорматив», перевод на русский язык, 2005. — 37с.
6. Указ Президента Республики Саха (Якутия) 12 июля 2011 года №809 «О министерстве сельского хозяйства и продовольственной политики Республики Саха (Якутия)»
7. BPWIN. [Электронный ресурс]. Режим доступа: http://erwin.com/worldwide/russian-russia (Дата обращения: 31.10.2015)
8. ARIS. [Электронный ресурс]. Режим доступа: http://www.softwareag.com/ru (Дата обращения: 31.10.2015)
9. RAMUS. [Электронный ресурс]. Режим доступа: http://ramussoftware/com (Дата обращения: 31.10.2015)
[1] «Процессный подход к управлению. Моделирование бизнес-процессов». РИА «Стандарты качества», 2004
[2] ISO 9000 «Системы менеджмента качества. Основные положения и словарь»
Источник: scienceforum.ru
О системах управления бизнес-процессами, кейс-менеджменте и актуальности принципа бритвы Оккама
Что такое Адаптивный кейс-менеджмент (ACM)? «BPM (управление бизнес-процессами) vs. ACM (адаптивный кейс-менеджмент)» – противопоставление или интеграция? ACM это часть BPM или самостоятельная концепция?
Системы управления бизнес-процессами позволяют автоматизировать структурированные и формализованные (или, как минимум, повторяющиеся) перечни работ, выполняемые на предприятии (например, обработка заказов клиентов, оформление командировок, процессы закупки оборудования и материалов и т.п.).
Однако, достаточно большая часть работ, выполняемых сотрудниками совместно, во взаимодействии между собой, слабо структурирована, требует обсуждений, выдачи поручений на основе анализа текущей ситуации и контроля сроков исполнения задач и поручений. Для решения подобных задач коллективного взаимодействия сотрудников, управления социальными бизнес-процессами и предназначены системы ACM (Adaptive Case Management).
Таким образом, управление бизнес-процессами и адаптивный кейс-менеджмент дополняют друг друга и позволяют автоматизировать как структурированные устоявшиеся бизнес-процессы предприятия, так и ежедневную коллективную работу сотрудников.
«Pidgin-BPM» или недостающее звено BPM?
«BPMs vs. ACM» – противопоставление или интеграция? ACM это часть BPM или самостоятельная концепция? Многочисленные дискуссии на эту тему буквально вспыхивают в разных концах Интернета и на страницах ИТ-изданий.
Ответ на этот вопрос зависит от позиционирования ACM. Можно наблюдать 2 тенденции среди экспертов.
Одни эксперты считают, что ACM это «Pidgin-BPM», примитивная версия BPM, вульгарным способом решающая те же проблемы, что и BPM. «Серьезные специалисты», отдавшие годы BPMN, BPEL etc., принять такую концепцию ACM не готовы, максимум, на что они вынуждены идти – это считать ACM опцией, дополнительным «бантиком» к BPM. Что интересно, большой вклад в популяризацию такой концепции ACM оказывают посты некоторых известных апологетов ACM (Max J. Pucher), считающих, что «Adaptive Case Management does not suppose collaboration». Однако именно практическим внедренцам прекрасно известно, что реальные системы BPM имеют вполне реальные проблемы с целостностью, под которой в данном случае понимаем возможности для удовлетворения всей полноты требований заказчика по автоматизации бизнес-процессов. Хорошо известно, что частенько происходит при возникновении непредвиденных (для системы BPM) проблем. Отодвигаемся в сторону от компьютера с его BPM-игрушками и беремся за телефон, чтобы «контролировать ситуацию» – со всеми вытекающими последствиями, в том числе и с последствиями для такой системы.
Естественно, поставщики давно видят наличие недостатков у «традиционных» BPM систем. Изобретаются различные возможности добавлять в экземпляр бизнес-процесса в режиме реального времени ad-hoc activity, появляются расширения BPEL для учета коллективного взаимодействия, такие как BPEL4People – однако эти возможности обладают общими недостатками BPM в сравнении с ACM – требуют сложных настроек (а в ACM их минимум), в них затруднены средства контроля доступа, адресации и фильтрации таких ad-hoc activities, нет средств загрузки файлов, фотографий пользователей, средств для ведения дискуссий – все это элементарные средства, которые обязаны быть в любой ACM.
Результатом такого подхода является ненужный антагонизм между ACM и BPM.
Другие эксперты считают, что ACM это collaborative BPM, social BPM, agile BPM, в которой следующий шаг процесса определяется в социальной среде решением человека. А этот как раз то «недостающее звено», чего не хватает традиционному BPM и почему изобретаются BPEL4People etc. В такой интерпретации ACM это как раз то, чего жаждет BPM, можно сказать, без чего BPM не сможет развиваться, чтобы наконец стать эффективным инструментом. И интеграция BPM и ACM в этом случае расширяет сферу применения BPM, делает системы BPM более привлекательными и эффективными. И те вендоры и интеграторы BPM, кто начинает интегрироваться с ACM, получают конкретные конкурентные преимущества
BPM без ACM «выражает одну из основных черт буржуазного мировоззрения — его бесчеловечность, стремление превратить трудящихся в придаток машины, заменить живого, мыслящего, борющегося за свои интересы человека машиной» (1954, Краткий философский словарь о кибернетике) Cool. Ну, а если это выразить более современно, то ACM привносит в BPM необходимую гибкость социальных сетей, «очеловечивает BPM», позволяя средствами web 2.0 интегрировать системы BPM с возможностями систем коллективной работы, помогающих принимать решения о следующих шагах бизнес-процесса в социальной среде, с помощью обсуждений и поручений.
Преимущества интеграции
Спорное убеждение некоторых, что ACM это часть BPM, а не самостоятельная «фича», можно усилить идеей о том, что ACM это не просто дополнительный «бантик» BPM, а критически важная часть, без которой практическая система BPM не является целостной – а отсутствие целостности, недостаток инструментов, собственно, часто и создает известные проблемы при внедрении, то самое желание отодвинуться в сторону от компьютера с и взяться за телефон.
Отсюда практический вывод – хотите, чтобы конкретная система BPM внедрялась успешно – интегрируйте ее с ACM и в этой связке внедряйте. Можно добавить и еще одну идею – более того, двигайте ACM первой – это проще, не нужен трудный инкубационный период анализа бизнес-процессов и создания их описаний для BPM, когда ничего еще не работает, но время и деньги заказчика вовсю тратятся. Имея работающую ACM, можно детально описать бизнес-процессы и внедрять BPM «поверх» работающей ACM, тем самым минимизируя известные проблемы запуска.
Такая тактика, как выясняется, является успешной и позволяет за счет ACM сгенерировать новую волну интереса и к системе BPM, которая при наличии в ней «недостающего звена» ACM, становится существенно более функционально привлекательной для заказчиков и более презентабельной внешне.
Добавление гибкости, адаптивности и средств коллективной работы в систему BPM, как уже совершенно очевидно, очень существенно повышает ценность такой системы BPM. Унаследованные приложения уже с трудом конкурируют с новыми web 2.0 системами, имеющими схожие функции, а «офейсбученный офисный пипл» жаждет привычного интерфейса и на работе тоже.
Из-за множества «исключений», сопровождающих бизнес-процессы в реальной корпоративной жизни далеко не все удается автоматизировать «традиционными» BPMS. Реализации получаются очень громоздкими из-за множественности и неопределенности этих исключений.
В «обычной» системе BPM вы должны изначально скрупулезно и детально перечислить все возможные варианты до начала процесса, в ACM эти варианты «подгружаются» из библиотеки паттернов или создаются вручную по мере их появления в реальности. Это как сравнивать простую статичную HTML-страницу, которая содержит сразу все нужное и ненужное, и HTML-страницу с AJAX, которая подгружает данные на страницу по мере необходимости. В принципе, можно как-то и простыми HTML-страницами обойтись, зачем этот AJAX? Однако, с ним лучше получается. Так и ACM «проявляет» процесс по мере его исполнения.
Можно сравнить существующие BPM-платформы с машиной Тюринга. В том смысле, что в рамках BPM-платформы возможно запрограммировать любые бизнес-процессы, так же как на виртуальной машине Тюринга можно теоретически запрограммировать все. Но только теоретически. Это доказано. Так и с «традиционными» BPMS – теоретически можно все.
А вот практически… Поэтому концепция ACM и появилась. Циклами Птолемея тоже, в принципе, движение звездных тел описывалось – с любой наперед заданной точностью.
Принцип Оккама безвозвратно забыт
Принцип бритвы Оккама «не изобретай сущностей сверх необходимых» безнадежно забыт очень многими вендорами ИТ, нынешний мировой тренд поставщиков программного обеспечения можно выразить фразой «новизна подменяется сложностью». Когда сказать нечего, идей нет, а новые версии надо выпускать, чтобы генерировать доход — на рынок выпускаются софтверные монстры. И с BPM такая же история.
Однако, забыть-то принцип Оккама можно, но только так же, как склероз, который забыть можно, а вылечить нельзя.
И появление ACM можно трактовать как ответ рынка на затянувшиеся мучения пользователей с BPM. Как возврат к простоте и фундаментальному принципу монаха Оккама.
Пользователи готовы пожертвовать функциональностью в пользу простоты. Это и есть причина появления концепции ACM. Грубо говоря, с BPM намучились, долго ждали чего-то простого и доступного – и вот дождались ACM.
Все гениальное простым становится позже, сначала оно кажется примитивным
Вместо сложных описаний бизнес-процессов весь Adaptive Case Management крутится фактически вокруг чек-листов, представляющих собой список из чек-пойнтов или milestones – контрольных точек, задач, которые необходимо выполнить.
Для ACM такой чек-лист из контрольных точек – это то же самое, что для «традиционного» BPM «happy path» – основной перечень действий, которые надо сделать и представление о которых имеется перед началом процесса. В ACM этот перечень по мере исполнения процесса корректируется и дополняется.
Собственно, обработка статусов контрольных точек (открытие, закрытие, отмена, деактивирование, приостановка, назначение и контроль сроков исполнения) + информационные сообщения (дискуссии и отчеты о предпринимаемых действиях) – это и есть основной функционал ACM.
Фильтры позволяют увидеть и на лету сформировать все такие необходимые списки контрольных точек в разных разрезах:
- «Открытые» – актуальные сообщения
- «Требующие ответа» – сообщения, требующие создания ответных сообщений
- «Просроченные» – открытые сообщения с просроченной датой исполнения
- «Созданные мной» – сообщения, созданные текущим пользователем
- «Для меня» – сообщения, адресованные текущему пользователю
- «Закрытые» – исполненные задачи
Системы ACM позволяют автоматизировать текущие процессы предприятия, требующие коллективного взаимодействия и совместной работы сотрудников, без какой-либо трудоемкой первоначальной настройки системы и без программирования. С их помощью можно организовать работу сотрудников таким образом, что сотрудники смогут видеть всю информацию о текущих проектах, в которых они участвуют, задачах и документах на одном экране. Работы, задачи, поручения и дискуссии по различным проектам можно представить как последовательности сообщений, вводимых в нужном порядке и содержащих описание, списки адресатов или исполнителей и сроки исполнения. Исполненные работы, задачи и поручения помечаются как закрытые сообщения (кейсы).
Последовательности сообщений, содержащие описания проблем, дискуссии пользователей, поручения и файлы образуют прецеденты, которые можно копировать в библиотеку шаблонов и использовать при решении аналогичных проблем и задач.
Например, именно так управление контрольными точками, задачами и поручениями для сотрудников реализовано в PayDox Case Management. Задачи и поручения для сотрудников можно создавать вручную (причем стандартные задачи для «ближнего круга» пользователей, с которыми общаешься чаще всех, создаются за пару кликов мыши), а можно одним нажатием кнопки создать из библиотеки шаблонов сразу целый кейс, т.е. иерархический список поручений и задач, которые необходимо исполнить.
Адаптивность системы в том, что нет необходимости заранее планировать весь список задач для какого-либо проекта или проблемы. Можно «решать проблемы по мере их поступления», создавая сотрудникам поручения по ходу дела. После завершения проекта все связанные с ним задачи можно пачкой скопировать в библиотеку шаблонов, отредактировав и удалив лишние и нетипичные. После этого для решения аналогичной проблемы или проекта можно одним кликом мыши создать из библиотеки шаблонов новый кейс, уже содержащий весь перечень задач, которые необходимо выполнить и список исполнителей, которые такие задачи уже решали. При активизации нового кейса исполнители получат уведомление по e-mail и смогут немедленно подключиться к работе, а весь процесс будет контролироваться системой.
Т.е., в отличие от систем Business Process Management систему Adaptive Case Management можно начать реально использовать практически немедленно после инсталляции, постепенно создавая и совершенствуя кейсы (последовательности задач и поручений) на любые темы — прием на работу и увольнение сотрудников, выполнение работ по договорам, обработка заказов и т.п. В системах BPM необходимо сначала описать и спроектировать все бизнес-процессы, что часто является камнем преткновения для реального внедрения BPMS.
Малому бизнесу нужны «варенки с вьетнамского рынка»
2 простых вопроса – какой процент крупных компаний используют системы BPM? 15%? Значит есть куда расти . А какой процент малых предприятий используют системы BPM? 0,01%? Значит, тут у «традиционных» систем BPM шансов нет.
«Чистые» BPMS являются элитарными, как джинсы Версаче, и малый бизнес никогда не сможет их использовать. А вот использовать системы ACM в силу их простоты и доступности смогут 90% малых предприятий – простая система управления задачами, где можно галочкой отмечать исполненные работы, нужна практически всем. Такие системы ACM будут, как «варенки с вьетнамского рынка» — дешевый и доступный товар массового спроса. Конечно, такие «варенки с вьетнамского рынка» не будут мейнстримом, функционал которых и его соответствие различным стандартам дотошно обсуждается крутыми ИТ-менеджерами в специализированных блогах — просто все будут их юзать без всякого почитания и ритуальных танцев с описанием бизнес-процессов и написанием толстых технических заданий.
Так что для элитарных BPMS со стороны ACM опасности никакой – BPMS на рынок SMB особо и не претендуют, их присутствия на этом рынке не ощущается – у них достаточно проблем и с крупными заказчиками пока.
И еще о «мейнстриме». Уж лет пять как можно заметить, что мейнстримом стали flea-markets. В Европе блошиные рынки и вьетнамские распродажи стали вытеснять обычные магазины. В самом центре Вены между Оперой и Гранд-отелем, где еще недавно был обувной бутик, теперь китайский магазинчик со всякой мелочью от 2 до 10 евро! К чему бы это?
Видимо, все банально – и блошиные рынки и ACM это ответ на вызов рынка. ACM это «BPMS для бедных»? А почему бы и нет?
И еще о сложных и простых ИТ-платформах
Известный факт – автоматизация на предприятии, в общем случае, вовсе не приводит к облегчению жизни пользователей, а часто совсем наоборот – пользователей вынуждают протоколировать все свои действия в автоматизированной системе, что отнимает у пользователей кучу времени и монополию на корпоративные знания, а, соответственно, и статус незаменимости у ключевых пользователей. От автоматизации выигрывают не сотрудники, а предприятие в целом.
Ну а сотрудники очень часто недовольны. И именно айтишники компании-заказчика часто влияют на выбор неоправданно более сложной системы с неоправданно более сложной архитектурой, тем самым укрепляя свою незаменимость. А пользователи интуитивно это чувствуют. Но доказать и поделать ничего не могут. И недовольны, кто-то осмысленно, кто-то интуитивно.
Известный факт, что сисадмина, у которого все хорошо, никто не замечает, а сисадмина, у которого все ломается, носят на руках, как героя, который всех спасает в критический момент.
Уже давно очевидно, что, предлагая на рынке простой в эксплуатации эффективный продукт со 100%-й гарантией успешного внедрения, ты, возможно, лишаешь себя наиболее крупных заказчиков с многочисленным штатом айтишников, которые по доброй воле такой продукт не выберут – их или жизнь это может заставить сделать позже или собственное начальство, озверевшее от жалоб пользователей на систему, работающую только в присутствии айтишников.
И еще на тему влияния корпоративной психологии на ИТ-архитектуру. Есть известная поговорка: «Ни одного менеджера еще не уволили за то, что он выбрал решения от IBM». И чем крупнее компания-заказчик, тем проще принимать такие решения.
При этом такие очевидные факты, что «решениям от очень крупного вендора» свойственны очень высокая стоимость владения (TCO), сомнительный возврат инвестиций (ROI) и высокий риск провала внедрения, в расчет не принимаются – ИТ-бюджет позволяет за все заплатить. Фактический провал такого внедрения долго никем не признается – никому это не выгодно – и решение существует в вялотекущем режиме, используется 10% заявленной функциональности. Но архитектура используется очень крутая (ну,и дорогая, соответственно). Виноваты все, кроме принявшего «правильное» решение менеджера.
Иногда только публике становятся известны удивительные факты судебных исков против поставщиков ERP о возмещении убытков на сотни миллионов долларов. Большие, сложные и дорогие ИТ-платформы нужны. Но в области систем управления бизнес-процессами они как-то уж очень превалировали, более того, малому бизнесу в этой сфере почти не на что было рассчитывать – в отличие, например, от бухгалтерских систем. Теперь возможности цивилизованно управлять бизнес-процессами появились у всех. Down-sizing приложений в этой сфере дает шанс малым предприятиям строить свой бизнес цивилизованно, с использованием самых современных информационных технологий.
Источник: www.tadviser.ru