Показаны сообщения с ярлыком бизнес-процесс. Показать все сообщения
Показаны сообщения с ярлыком бизнес-процесс. Показать все сообщения

вторник, 26 мая 2026 г.

Как регулировать доступ ИИ к ERP-системам и финансовым системам

Основная проблема

ИИ-агенты и копилоты получают беспрецедентный доступ к данным ERP и финансовых систем, действуя с «машинной скоростью». Традиционные модели контроля, рассчитанные на людей, не работают.

Отсутствие управления создает риски: непрозрачные потоки данных, скрытые нарушения разделения обязанностей (SoD) и появление «призрачных» машинных идентификаторов, которые не отслеживаются и живут дольше проектов или сотрудников.

Три пути проникновения ИИ в ERP

  • Встроенные копилоты ERP (например, от SAP или Oracle). Риск: они часто наделяются избыточными правами, а их активность не отделяется в логах от действий человека.
  • Внешние ИИ-агенты через API. Риск: используют долгоживущие ключи и общие служебные учетные записи, что не позволяет атрибутировать действия и соблюдать SoD.
  • Теневой ИИ (Shadow AI). Риск: выгрузка данных в Excel или BI-инструменты с последующим использованием в неконтролируемых ИИ-сервисах, что обходит все официальные каналы мониторинга.

Общий корень проблемы

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

Три принципа правильного управления (что такое «хорошо»)

  • ИИ-агенты как полноценные идентификаторы (first-class identities). У каждого должен быть владелец, бизнес-цель и профиль риска, а не общая техническая учетка.
  • Доступ на основе политик, а не разовых заявок. Выдача прав должна проходить через стандартные рабочие процессы с проверкой SoD.
  • Сквозные, готовые к аудиту треки. Возможность в любой момент показать, где живет ИИ, к чему имеет доступ, кто одобрил и когда проводился последний обзор.

Жизненный цикл ИИ (JML — Joiner, Mover, Leaver)

  • Joiner (Присоединение). Новый ИИ-кейс проходит предсказуемый путь: сбор требований, назначение ответственного владельца и классификация риска, выдача доступа строго по политике.
  • Mover (Изменение). Любое расширение прав (новые коды компаний, доступ к проводкам) автоматически запускает переоценку рисков и новые согласования, не позволяя правам накапливаться.
  • Leaver (Увольнение). При завершении проекта или истечении срока контракта все учетные данные ИИ (ключи, токены, роли) должны автоматически отзываться, а доказательства активности — сохраняться для аудита.

Практические шаги: чек-лист из 10 пунктов (краткое резюме для руководителей CISO, CFO)

  • Создать единый реестр всех ИИ-идентификаторов.
  • Назначить каждому владельца и категорию риска.
  • Встроить ИИ в стандартные процессы JML.
  • Определить политики доступа и правила SoD для ИИ.
  • Заменить общие служебные аккаунты на управляемые ИИ-идентичности.
  • Требовать согласования доступа ИИ к чувствительным данным по политике.
  • Включить ИИ в регулярные кампании по ресертификации доступов.
  • Включить непрерывный мониторинг активности ИИ и аномалий.
  • Автоматически отзывать доступ при завершении проектов.
  • Регулярно отчитываться перед комитетами по аудиту о метриках доступа ИИ.

Ключевая мысль: Управление доступом ИИ к ERP должно рассматриваться не как техническая проблема безопасности, а как проблема управления идентификациями (identity governance). Решение — распространить дисциплину, применяемую к привилегированным пользователям, на мир нечеловеческих и ИИ-идентичностей.

Источник - телеграмм-канал Data secrets

понедельник, 17 февраля 2025 г.

Фазы развития технологии ИИ

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

Понимание технологий общего назначения и их фаз


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

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

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

Четыре основные фазы развития технологий общего назначения:
  • Текущее состояние: До того, как технология получила широкое распространение, отрасли работали исторически состоящей структуре, используя устоявшиеся процессы. Процессы часто являлись ручными и не обладали эффективностью по сравнении с эффективность новой технологии. В случае с электричеством, например, фабрики полагались на централизованные паровые двигатели для питания машин, что требовало жесткой компоновки, многочисленных регулировок и высокого уровня обслуживания.
  • Точечные решения: Первоначальное использование технологии, как правило, фокусировалось на изолированных задачах или функциях, которые улучшаются для конкретных выгод без фундаментального изменения системы. Ранние последователи электричества заменили паровые двигатели электродвигателями, но сохранили модель центрального приводного вала, увидев улучшения в надежности питания и управлении без структурных изменений.
  • Более широкие применения: По мере того, как технология распространяется по функциям, она начинает создавать взаимосвязи, которые повышают общую производительность. Когда электродвигатели начали приводить в действие отдельные машины, заводские планировки стали гибкими, что повысило производительность, при этом продолжая следовать структурам сборочной линии.
  • Изменение на уровне системы: На последнем этапе происходит фундаментальная перестройка операций или целых отраслей. Когда фабрики полностью перешли на электричество, они смогли избавиться от центральных шахт, децентрализовать операции и внедрить сборочные линии, обеспечив производство «точно вовремя» и большую масштабируемость. Это изменение на уровне системы переопределило производство и заложило основу для современной промышленности.

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

Парадокс производительности


Прошлые технологии общего назначения, такие как электричество, демонстрируют закономерность, известную как «парадокс производительности», когда для материализации роста производительности могут потребоваться десятилетия. Экономист Пол Дэвид заметил, что электричеству потребовалось около 40 лет, чтобы появиться в статистике производительности. Ранние последователи часто использовали новую технологию для имитации старых процессов, ограничивая ее преобразующий потенциал, пока организации не адаптировались к использованию ее уникальных возможностей. Эта задержка показывает, что для ускорения потенциала производительности ИИ требуется нечто большее, чем улучшения на основе задач.

Ускорение развития ИИ


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

Принять отказ от обучения как основную стратегию лидерства. В быстро меняющемся мире ИИ и других преобразующих технологий способность учиться, рузучиваться и переучиваться становится критически важной. Проницательность Элвина Тоффлера — «Неграмотными в 21 веке будут не те, кто не умеет читать или писать, а те, кто не умеет учиться, разучиваться и переучиваться» — подчеркивает важнейший навык отказа от устаревших знаний для адаптации к новым реалиям. Лидеры должны активно развивать мышление, которое бросает вызов существующим предположениям, постоянно подвергает сомнению статус-кво и принимает новые идеи. Отучивание позволяет лидерам и организациям оставаться гибкими, избегая жесткости, которая душит инновации. Отказываясь от укоренившихся способов мышления, лидеры могут лучше позиционировать свои команды для принятия новых перспектив, проведения системных изменений и процветания в мире, сформированном универсальными технологиями, такими как ИИ.

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

Репетиция будущего. Поскольку путь ИИ трудно предсказать, лидерам следует проводить структурированные «репетиции будущего», исследуя сценарии, основанные на ИИ, чтобы понять потенциальные воздействия и риски. Репетиции будущего дают представление об изменениях на уровне системы и готовят организации к адаптивности и устойчивости в условиях быстрых технологических сдвигов.

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

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

Инвестиции в долгосрочные структуры поддержки. Хотя внедрение новых технологий, таких как ИИ, может принести дополнительные выгоды, лидеры должны признать, что для полного повышения производительности требуется время и фундаментальная поддержка. Создание правильной инфраструктуры, процессов и навыков в организации не происходит в одночасье. Помимо простого внедрения технологии, организации должны инвестировать в адаптацию своей среды и процессов, чтобы раскрыть ее полное влияние. Лидеры, которые сосредоточены на создании сильной экосистемы поддержки — от надежных структур данных до программ обучения — позиционируют свои организации для поддержания и максимального использования преобразующего потенциала этих технологий. Этот терпеливый, долгосрочный подход обеспечивает более плавный и эффективный путь через фазы внедрения технологии, позволяя масштабируемый рост.

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

Использование преобразующего потенциала ИИ


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

Источник


Раскрытие возможностей искусственного интеллекта как универсальной технологии. Фрэнк Диана. 30.10.2024 г.

https://frankdiana.net/2024/10/30/unleashing-artificial-intelligence-as-a-general-purpose-technology/

Unleashing Artificial Intelligence As A General-Purpose Technology. October 30, 2024 Frank Diana

среда, 20 ноября 2024 г.

Бизнес-процесс - как это может выглядеть

В статье McKensey (ссылка внизу) приведен примечательный рисунок в части построения и реализации бизнес-процессов. Для нетривиальных бизнес-процессов это почти стопроцентное попадание.

Итак

Процесс должен выглядеть так.




Процесс был реализован так.




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



Актуальный бизнес-процесс.




Вот так то.




Оригинальный рисунок выглядит следующим образом:





Источник.

Today’s industrial revolution calls for an organization to match. July 23, 2024. Article. By Dado Misljencevic, Sven Houthuys, Tom Welchman and Ulf Schrader

https://www.mckinsey.com/capabilities/operations/our-insights/todays-industrial-revolution-calls-for-an-organization-to-match

воскресенье, 21 апреля 2024 г.

Простой инструмент планирования

SIPOC - пожалуй самый простой инструмент описания бизнес-процессов. Аббривиатура расшифровывается так:
  • suppliers - поставщики, 
  • inputs - входы, 
  • process- процесс, 
  • outputs - выходы, 
  • customers - потребители.

Плюсы этого инструмента
  • простой,
  • достачно экселя для работы.

Впрочем, стоит упомянуть и минусы:
  • Невозможно представить иерархии.
  • Нет графики, например, аналогичной диаграммам Ганта.
  • Трудно оценить непротиворичивость входов и выходов.

Пример таблицы и пример заполнения.

Supplier

Поставщик

Input

Вход

Process

Процесс

Output

Выход

Consumer

Поставщик

Маркетинг

Отчет анализа рынка

Разработка новой продукции

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

Производство

Продажи

Продажи

Отчет по продажам

Пересмотр ассортимента

Изменения номенклатурных групп, запросы на новую продукцию, запросы на вывод ассортимента

Производство

Продажи


четверг, 15 февраля 2024 г.

Неопределенность и стратегия

Отсутствие уверенности в будущем – та самая причина, по которой нужна стратегия. Неопределенность присутствует всюду в стратегии и вокруг нее. Если все определенно, то достаточно плана для перехода от А к Б. Значит ли это, что неопределенность будущего и есть та насущная необходимость разработки стратегии. Похоже на это.

Бизнес не может все контролировить: он не может контролировать экономику, политику, политические события и действия конкурентов. Такую неопределенность требуется учитывать. Неопределенности, проистекающая из не подлежащих контролю событий и окружения. Учитывается ли ясным и надежным образом неопределенность при разработке стратегии. При обсуждениях часто отсутствует правильное планирование различных вариантов развития событий. Вместо этого обычно рассматривают одну версию будущего без понимания вероятности осуществления такой версии.

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

Почему мы избегаем иметь дело с неопределенностью? Возможно, в склонности рассматривать стратегию как чисто интеллектуальное упражнение — своего рода корпоративную игру. Однако стратегия ставит перед собой решение особого типа редких задач с высокой степенью неопределенности. К решению таких задач человеческий мозг наименее приспособлен. Люди подвержены когнитивным искажениям, среди которых чрезмерная самоуверенность, привязанность, неприятие потерь, предвзятость подтверждения и ошибки атрибуции. Эти непреднамеренные мысленные способы оценки помогают нам в повседневной деятельности фильтровать информацию. Но они искажают решение долгосрочных задач с высокой неопределенностью. И именно такие задачи рассматривает стратегия.

Даже самые опытные руководители имеют лишь ограниченный опыт и способность распознавать закономерности в таких ситуациях. Им приходится принимать решения на основе ограниченной информации, а результаты могут не проявляться годами. В то же время любое количество факторов — человеческий фактор, рынок, отставание и «шум» — может вмешаться и подавить способность любого стратега предсказать результат.

Неумение работать с неопределенностью


Электронные таблицы не предназначены для отображения диапазонов и учета шансов. Таблицы рассчитаны на конкретные числа, поэтому трудно осознать 75% вероятность того, что значение окажется между X и Y, а само значение получнео из тысяч ячеек корпоративного бюджета.

Мы игнорируем неопределенность. Многие презентации стратегий начинаются с прогноза рынка, основанного на аналитиках. Не сценарий, не набор исходов, а «наиболее вероятная версия будущего». И это последнее, что можно услышать о неопределенности в презентации. С этого момента вы получаете точечные оценки плана. «Я не могу справиться с множеством реальностей», — сказал нам один генеральный директор. «Я лучше выберу мир, в котором живу».

Мы относимся к неопределенности как к второстепенной мысли. Стратегическая комната — суровое место для большинства, и, откровенно говоря, неудача на этом этапе не является вариантом для большинства менеджеров. Проблемы с исполнением? ХОРОШО. Стратегия, в которой есть пробелы? Мы можем это исправить. Но стратегический разговор о вероятностях? Ты должно быть шутите! Вместо этого вы получаете слайд о рисках на странице 149 150-страничной колоды, озаглавленный примерно так: «Потенциальные проблемы риска и способы их смягчения». Это сделано для того, чтобы докладчик мог сказать, что проблема раскрыта, если возникнет вопрос о риске.

Мы притворяемся, что имеем дело с неопределенностью. В некоторых случаях неопределенность действительно обсуждается в стратегической комнате. Скажем, геополитические потрясения угрожают росту продаж на развивающемся рынке или есть признаки того, что конкурент может предпринять шаги по консолидации отрасли. Можно представить несколько сценариев, после чего следует обсуждение того, какой из них более или менее вероятен. Затем один сценарий выбирается в качестве «базового», и это, вероятно, последнее, что вы слышите о неопределенности. Стратегия ясна, работа сделана.

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

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

Понимание причин


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

При выборе стимулов, бонусов и продвижения по службе снова в игру вступают неопределенность и вероятности. Поскольку мы все хотим добиться успеха, большинство из нас предпочтут план, который мы выполним с вероятностью 90%, плану, который мы выполним только в 50% случаев. Фактически, многие бизнес-лидеры спокойно признают, что они соглашаются только с теми бюджетными целями, которые, по их мнению, могут достичь их почти наверняка 100%, за исключением каких-либо совершенно неожиданных сбоев. Тем не менее, когда мы спрашиваем руководителей, что было бы справедливо в отношении промахов, многие из них говорят, что каждые три-четыре года лидер может не выполнять план. Это большая разница во взглядах.

Учет вероятностей может сделать оценку эффективности и результатов чрезвычайно сложной. В этом случае гораздо труднее определить ключевые показатели эффективности.

От уверенности к вероятности


McKensey провела анализ экономической прибыли почти 2400 компаний за 10 летний период и сделала заключение, что эффективность отрасли определяет почти половину успеха компании. Фактически, влияние отрасли настолько существенно, что лучше быть средней компанией в великой отрасли, чем великой компанией в средней отрасли. Далее было сделано заключение, что шансы на то, что компания перейдет из среднего квинтиля в верхний за десятилетний период составляет всего 8%.

Обнаружено, что 10 переменных объясняют почти 90% положения компании. Они делятся на три категории:
  • возможности (с чего вы начинаете), 
  • тенденции (встречные или попутные ветры),
  • действия (пять предпринимаемых стратегических действий).

Сопоставление этих переменных с переменными конкурентными или с кривой от Mckensey позволяет уменьшить оптимистические надежды и более трезво оценить вероятность успеха.

Исследование также показало, что примерно 40% успешных компаний в течение десятилетия скатятся вниз.

Если каждая из пяти компаний имеет 80% шанс на успех, это все равно означает, что одна из них обычно терпит неудачу. Если каждая из пяти компаний имеет 20% шанс на успех, одна из пяти, скорее всего, выиграет. Очевидно, что лучшая стратегия — это та, вероятность успеха которой составляет 80%, и именно ей следует отдать должное, независимо от того, выиграете вы или проиграете.

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

Оценка риска необходима для принятия решения о том, когда их стоит принимать, и для того, чтобы подтолкнуть других к их принятию. Если у вас лишь небольшой шанс на выигрыш, но ставка стоит мало, а потенциальный выигрыш огромен, это все равно может оказаться стоящей инвестицией. Обратное тоже верно. Дорогостоящие инвестиции, которые создают высокую вероятность небольшого успеха, могут оказаться плохой идеей. Игроки в покер называют такие расчеты «шансами банка». Если ставка в 100 долларов дает вам 20% шанс выиграть банк в 200 долларов, вы сбрасываете карты. По сути, вы платите 100 долларов за 40 долларов — это 20% от 200 долларов. Но ставку в 100 долларов, которая дает вам 20% шанс выиграть банк в 2000 долларов, вы делаете каждый раз, потому что вы платите 100 долларов, чтобы получить 400 долларов — 20% от 2000 долларов. Таким образом, оценка шансов — среди прочего, конкурентных, рыночных и нормативных — должна быть частью расчетов.

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

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

Источник


https://www.mckinsey.com/capabilities/strategy-and-corporate-finance/our-insights/how-to-confront-uncertainty-in-your-strategy

Chris Bradley, Martin Hirt, Sven Smit. How to confront uncertainty in your strategy. 23.03.2018.
Как противостоять неопределенности в вашей стратегии. 23.03.2018. Отрывок из книги.

воскресенье, 6 марта 2022 г.

Пофилософствуем: Бизнес-модель и бизнес-процесс

В основе бизнес-модели должны, как мне представляется, должны лежать следующие принципы:

- бизнес-функции: описывают ЧТО делает бизнес;
- бизнес-процессы: описывают КАК предприятие выполняет свои бизнес-функции;
- организационная структура: определяет ГДЕ исполняются бизнес-функции и бизнес-процессы;
- существуют фазы, определяющие КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
- роли, определяющие КТО исполняет бизнес-процессы;
- правила, определяющие связь «ЧТО, КАК, ГДЕ, КОГДА и КТО».

Ответы же на вопросы "ЗАЧЕМ" или "ПОЧЕМУ" определяют бизнес-идею и следующую за бизнес-идеей стратегию.

* * *

Процедура идентификации бизнес-процесса как объекта.
  1. Какая основная функция объекта (процесса)
  2. Что представляет собой идеальный объект (процесс)
  3. Что будет если убрать объект (процесс)
  4. Список функций объекта (процесса)
  5. Проверка - нельзя ли убрать какую-либо функцию
  6. Какие другие способы выполнения основной функции
  7. Есть ли область, где функция выполняется наилучшим способом. Нельзя ли позаимствовать оттуда способ выполнения
  8. Можно ли разделить на части объект (процесс)
  9. Можно ли выделить слабое звено
  10. Можно ли объединить несколько звеньев
  11. Подвижность или неподвижность элементов, можно ли менять подвижность
  12. Нельзя ли поменять последовательность операций.
  13. Нельзя ли исключить вспомогательные и подготовительные операции
  14. Нельзя ли использовать вредные факторы и функции
  15. Дополнительные функции объекта
  16. Где в объекте излишние запасы, как их сократить

четверг, 13 января 2022 г.

Причины неудач в управлении бизнес-процессами

5 причин неудач в управлении бизнес-процессами


1. Отсутствие акцента на стандартизации


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

И обязательно стоит проверить - почему тот или иной бизнес-процесс выполняется именно так, а не иначе. Вполне возможно, что так просто сложилось исторически, без веской бизнес-причины.

2. Автоматизация неэффективных процессов


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

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

Потратьте время на то, чтобы улучшить бизнес-процессы до внедрения ERP. Но улучшение бизнес-процессов - это отдельный процесс и он отличается от стандартизации. И это процесс стоит начинать как можно раньше.

3. Недостаточное вовлечение сотрудников


Ваша проектная группа ERP работает изолированно? А ведь без участия автоматизируемых сотрудников можно что-нибудь (и даже много) упустить.

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

4. Отсутствие поддержки со стороны руководства


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

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

5. Пренебрежение управлением организационными изменениями


Всякий раз в ходе изменения бизнес-процессов неизбежны несогласие и сопротивление. Это особенно актуально, если изменяются «проверенные» бизнес-процессы.

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

Как можно раньше и "сверху" должна быть организована коммуникация и руководители должны четко сообщать сотрудникам об ожидаемых изменениях, делясь ключевыми деталями, включая:
  • Почему меняется компания.
  • Почему изменение происходит сейчас.
  • Какие именно процессы будут меняться.
  • Что останется прежним.
  • Риски, которые могут возникнуть, если компания не примет изменения.

Есди информация распространяется свободно, создаются предпосылки запуска ERP c наибольшими шансами на успех.

Вывод


Хотя ERP-система может повысить эффективность и прозрачность бизнес-процессов, важно перед внедрением внести определенные улучшения в бизнес-процессы. Рекомендуется сосредоточиться на улучшениях, которые, как ожидается, принесут наибольшую пользу с наименьшими усилиями.

По материалам "Причины неудач в управлении бизнес-процессами от Panorama Consulting Group. 19 октября 2020 г."

вторник, 19 октября 2021 г.

Карта покупательского поведения

Что такое карта покупательского поведения клиента? 

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

В контексте внедрения ERP карта покупательского поведения клиента может помочь улучшить бизнес-процессы перед их автоматизацией. Это также может помочь определить обязательные требования к программному обеспечению.

Поведения клиентов не простое. Каждый раз, когда кто-то взаимодействует с брендом, он отправляется в индивидуальное покупательское путешествие. На первый взгляд это путешествие может показаться простым. Вы предлагаете клиенту понравившийся ему товар или услугу. Он рассматривает товар, расспрашивает о его свойствах и решается купить. Достаточно просто, правда? Не очень, если учесть, что средний человек сейчас использует до десяти различных каналов для выбора товара или услуги. То есть путь к покупке сложен и многогранен.

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

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

Карта покупательского поведения - это одна или несколько диаграмм. Карта должна отражать взаимодействие клиентов с брендом и их восприятие бренда в разных каналах. В каких каналах? Таким каналами могут быть:
  • Веб-сайты.
  • Социальные медиа.
  • "Органический" поиск (результаты выдачи поисковых машин).
  • Платный поиск.
  • Электронная почта.
  • Телефон.
  • Чат.
  • Мобильные устройства.

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

Как построить карту покупательского поведения клиента


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

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

Шаги создания карты покупательского поведения клиента.

1. Идентификация всех точек взаимодействия с клиентами


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

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

2. Персонификация покупателя


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

3. Картирование пути покупателя


Часто компании разделяют взаимодействие с клиентами на отдельные этапы. Например, на такие этапы:
  • Осведомленность.
  • Рассмотрение.
  • Решение о покупке.
  • Обслуживание клиентов.
  • Лояльность к продукту/бренду.

4. Учет удовлетворенности клиентов и других показателей клиентского поведения


Как клиенты чувствуют себя на каждом этапе пути к обладанию продуктом или потребления услуги? Эмоции играют важную роль в клиентском опыте и должны быть неотъемлемой частью карты.

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

Независимо от того, какое действие совершено, у клиентов есть цель и эта цель может быть опеределена. Если действия клиентов будут успешными, они быстро достигнут своих целей. И их эмоции будут положительными. Однако, если клиенты столкнутся с препятствиями, может произойти и обратное.

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

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

Почему нужно планировать покупательское поведение клиента до выбора ERP?


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

Каковы другие преимущества составления карты покупательского поведения клиента?


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

Что это значит? 
Это значит:
  • Создание персонализированного клиентского опыта.
  • Понимание - чего хотят клиенты.
  • Выявление пробелов, которые могут повлиять на качество обслуживания клиентов.
  • Сравнение желаний клиентов с текущим клиентским опытом.
  • Визуализация движения клиентов в воронке продаж
  • Создание целостной логической структуруы клиентского пути.

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

Вывод


Что такое карта покупательского поведения клиента? Это диаграмма или серия диаграмм, которые показывают, как люди переходят из состояния потенциального покупателя к состоянию  актуального клиента. В карте покупательского поведения клиента подробно описано, как люди взаимодействуют с компанией и какие шаги предпринимают люди до и после принятия решения о покупке.

Источник заметки:

https://www.panorama-consulting.com/what-is-a-customer-journey-map/?utm_medium=email&_hsenc=p2ANqtz-_Sx3MFctHyVUgAD27rl-pmJK6FTEJLs8ilq-l0I54_MR_SjRkxI1aztYvNdmPfKSkSIrGIp5B1iEE6S25hMoQU1HFUOQ&_hsmi=140175897&utm_content=140125623&utm_source=hs_email&hsCtaTracking=58e8d0fa-87bf-4fbd-8dff-0af177d093c2%7C1d74821e-23fe-4b5d-a932-741fc1901a0d

What is a Customer Journey Map? [Is it Necessary for ERP Success?]
by Panorama Consulting Group | Jul 12, 2021

воскресенье, 17 января 2021 г.

Алгоритмическое доверие

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

Одна из технологий - authenticated provenance - Подтвержденное происхождение. Это способ аутентифицировать активы в цепочке блоков и гарантировать, что они не являются поддельными или скомпроментированными. Хотя блокчейн можно использовать для аутентификации товаров, эта технология также  может отслеживать документы и информацию.

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

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

В части технологий искусственного интеллекта также рассматриваются этичный ИИ (responsible AI) и понятный или обьяснимый ИИ (explainable AI). Последний вид искусственного интеллекта вызван особенностями нейронных сетей и невозможностью обьяснять, почему получен тот или иной результат на выходе нейронной сети.


В рамках этой темы стоит упомянуть о записи рабочих разговоров. К 2025 году 75% разговоров на работе будут записаны и проанализированы.

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

пятница, 24 июля 2020 г.

Классификация задач пользователя

В части задач пользователя стоит упомянуть о классификации задач:

  • РУТИННАЯ ЗАДАЧА. Процессно-ориентированные действия или исключения, которые происходят на регулярной основе и быстро обрабатываются.
  • "РЕАКТИВНАЯ ЗАДАЧА". Реактивное разрешение инцидентов (так называемое «пожаротушение») на основе внешнего триггера.
  • ЗАДАЧА МОНИТОРИНГА. KPI, измерение или мониторинг состояния в определенной области, а также деятельность по поглощению информации с открытыми результатами.
  • АНАЛИТИЧЕСКАЯ ЗАДАЧА. Анализ первопричин и анализ данных с открытыми результатами. Основы стратегического планирования и прогнозирования деятельности.
  • ЭКСПЕРТНАЯ ЗАДАЧА. Планирование действий и сложной обработки исключений, а также проектирование и конфигурирование системы.

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

суббота, 6 июня 2020 г.

Простая бизнес-модель

В статье HBR была опубликована простая бизнес-модель.
Текст статьи описывает проблематику.
Из этой проблематики я вынес следующий сухой остаток.
Чтобы создать модель - нужно ответить на следующие вопросы.
Они не решат проблему, но приблизят к ее решению.
Или возможно, отвратят от построения бизнес-модели.

Итак, исходные данные к созданию бизнеса.
Это простые вопросы.
Ответы могут быть сложными, если таковые будут.

Ключевые ресурсы
  • Какие ключевые ресурсы?
  • Где приобретаются ключевые ресурсы?
Ключевые партнеры
  • Кто ваши ключевые партнеры?
  • Какие ключевые направления деятельности партнеров?
  • Каковы ключевые ресурсы приобретаются у партнеров?
  • Кто ваши ключевые поставщики?
  • Каковы ключевые ресурсы приобретаются у постащиков?
Ключевые направления деятельности
  • Ключевые продукты или услуги?
  • Ключевые направления деятельности?
  • Каковы каналы продаж?
  • Взаимоотношения с потребителями?
  • Каковы потоки доходов?
  • Каковы потоки расходов?
Потребительская привлекательность
  • Какие нужды потребителей мы удовлетворяем?
  • Что ценного предлагается потребителям?
  • Какую проблему клиентов помогает решить наш продукт?
  • Что такое минимально жизнеспособный продукт?
  • Какие пакеты продуктов и услуг предлагаются каждому потребительскому сегменту?
Взаимоотношения с потребителями
  • Как мы привлекаем потребителей, как сохраняем их и как пополняем их ряды?
  • Какие мы выстроим взаимоотношения с потребителями?
  • Как взаимоотношения с потребителями сочетаются с остальными элементами бизнес-модели?
  • Во сколько обходятся взаимоотношения с потребителями?
Потребительские сегменты
  • Для кого производим продукт?
  • Кто наши главные потребители?
  • Что собой представляют наши типичные потребители?
Структура издержек
  • Основные издержки бизнес-модели?
  • Какие ключевые ресурсы самые дорогие?
  • Какие направления деятельности самые дорогие?
Потоки доходов
  • За какой продукт потребители готовы платить?
  • За что они платят сейчас?
  • Какова модель получения доходов?
  • Какова тактика ценообразования?

вторник, 2 июня 2020 г.

Модель принятия решений

Модель принятия решений и нотация (DMN) - подход для описания и моделирования повторяющихся решений в рамках организации.

Нотация и стандарт DMN служат для моделирования вырабоки решений, что позволит управлять процессом выработки решений на основе бизнес-правил. Нотация призвана поддерживать возможность чтения модели как бизнес-пользователями, так и ИТ-пользователями. Это, в свою очередь, позволяет различным группам лиц эффективно сотрудничать в определении модели решения. Например:

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

Стандарт DMN применяться как автономно, так и дополнять стандарты BPMN и CMMN. Более того, DMN дополняет BPMN, обеспечивая разделение интересов между процессом принятия решением и управляемым процессом.

Стандарт включает в себя три основных элемента.

  • Диаграммы принятия решений (Decision Requirements Diagrams). Показывают, как элементы принятия решений связаны в сеть зависимостей.
  • Бизнес-контекст принятия решений, в частности, роли организаций или влияние на метрики производительности.
  • Язык выражений (FEEL).

Определяют три основных варианта использования DMN.

  • Определение принятия решений в неавтоматизорованном режиме.
  • Определение требований для автоматического принятия решений.
  • Разработка и представление полной, выполнимой модели принятия решений.

При этом интеллектуальный анализ решений дополняет процессный анализ традиционными подходами к интеллектуальному анализу данных.

Использование стандарта DMN позволяет улучшить как анализ бизнес-процессов, так и управление ими. У стандарта есть следующие преимущества по сравнению с другими способами описания бизнес-процессов, так как

  • такие методы, как BPMN и UML, не поддерживают модели принятие решений;
  • способствуют лучшей коммуникации между бизнесом, ИТ и аналитиками компании;
  • обеспечивают представление таблиц решений

DMN был разработан для работы с BPMN. Модели бизнес-процессов можно упростить, перенеся логику процесса принятия решения в службы принятия решений. DMN - это отдельная область OMG, который представляет собой способ подключения к процессам модели BPMN. Решения в DMN могут быть явно связаны с процессами и задачами, которые используют решения. Предполагается, что с использованием DMN логика прннятия решений будет развернута как служба. Такая служба может быть вызвана из бизнес-процесса, и данные процесса могут быть сопоставлены с входами и выходами службы принятия решений. Это подход - «Решения как услуга».

пятница, 29 мая 2020 г.

SVBR или семантика делового словаря и семантика бизнес-правил

Полезен для использования в рамках BPMN.

Данная заметка пересказ заметки (в момент написания она была только на английском языке) -
https://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules

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

SBVR является неотъемлемой частью MDA - управляемой моделью архитектуры OMG (MDA - концепция модельно ориентированного подхода к разработке программного обеспечения).

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

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

SBVR с одной стороны использует естественный язык в моделировании, а с другой, явно предоставляет собой модель формальной логики. SBVR - это слияние лингвистики, логики и информатики, и все это используется для сбора и созданий спецификаций, изложенных на естественном языке и представленных средствами формальной логики.

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

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

Концептуализация и представление играют фундаментальную роль в мышлении, общении и моделировании. Концент может "разложен" на

  1. концепт в наших умах, 
  2. вещи реального мира, отображаенмые в концепте,
  3. представление концепта, которое мы можем использовать,  о котором думать, которое сообщать.


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

Концептуальная схема - это сочетание понятий и фактов того, что

  • возможно, 
  • необходимо, 
  • допустимо, 
  • обязательно 

в каждом возможном мире.

Множество фактов создает концептуальную схему путем утверждений (предложений) о возможным мире.

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

SBVR содержит словарь для концептуального моделирования и "сборку" выражений, основываясь на словаре. Выражения представляют собой формальные логические структуры.

Словарь SBVR позволяет формально определять представления концепций, определений, экземпляров и правил в любой области знаний  с испльзованием естественного языка. Эти функции делают SBVR приемлемым инструментом описания бизнес-областей, требований к бизнес-процессам и информационным системам.

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

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

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

Схема объявляет:

  • соответствующие типы фактов
  • соответствующие бизнес-правила

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

Вывод фактов.

  • Вывод означает либо то, как один тип факта может быть получен из другого.
  • Или, как понятие может быть определено в терминах других типов объектов и типов фактов

Подход к управлению, основанный на правилах, направлен на пользователей двух разных типов:

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


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

Логика, поддерживаемая SBVR, - это типизированная логика предикатов первого порядка. Интерпретация семантических формулировок SBVR основана на теории моделей.

SBVR фиксирует бизнес-факты и бизнес-правила, которые могут быть выражены в неформальной или формальной форме. Выражения бизнес-правил являются формальными только в том случае, если они выражаются исключительно в терминах типов фактов в предварительно объявленной схеме, в терминах определенных логических/математических операторов и квантификаторов. Формальные правила преобразуются в логическую формулировку, которая используется для обмена с другими инструментами. Неофициальные правила могут быть заменены как не интерпретированные комментарии. Имеется также подход к автоматической генерации бизнес-правил SBVR.

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

Подход SBVR предоставляет средства (то есть правила отображения) для перевода артефактов естественного языка в артефакты, совместимые со специфакаций мета-объектной модели MOF.

понедельник, 25 мая 2020 г.

BPMN

https://en.wikipedia.org/wiki/Business_Process_Model_and_Notation

BPMN (англ. Business Process Model and Notation, нотация и модель бизнес-процессов) — система условных обозначений (нотация) и их описания в XML для моделирования бизнес-процессов.

BPMN не используется для построения:
  • моделей данных,
  • организационных структур,
  • схем информационных потоков.
Для моделирования используются графические элементы, которые можно разделить на 4 категории:
  • Объекты потока управления: события, действия и логические операторы (развилки)
  • Соединяющие объекты: поток управления, поток сообщений и ассоциации
  • Роли: пулы и дорожки
  • Артефакты: данные, группы и текстовые аннотации.
Основные графические примитивы
  • кружки - это события
  • прямоугольники - это действия
  • ромбы - логические операторы. которые определяют развилки
  • стрелки - соединения перечисленного выше
  • полосы, описываеме как "пулы" и "дорожки" - это роли
  • всякие другие графические значки, типа скобки, выноски, изображения документов - это "прочие артефакты".
Отдельное пояснение касательно "пулов" и "дорожек", описывающих роли. Хорошая аналогия - бассейн с плавательными дорожками. Пул соответствует бассейну, дорожка - с пловцом.
Соответственно, когда вы чертите диаграмму - вам нужно четко разделить участников процесса, - сначала по бассейнам (пулам), а внутри каждого пула - по дорожками.
И здесь возникает довольно много ошибок, состоящих в том, что "пловцы" из разных бассейнов вдруг оказываются на соседних дорожках или даже все на одной дорожке.

В линейке продуктов SAP имеется приложение для построения BPMN диаграмм - SAP Power Disigner. Изложение деталей  построения BPMN диаграмм проведем опираясь на документацию этого продукта.

SAP PowerDesigner предоставляет поддержку двух вариантов BPMN 2.0:
  • Описательная BPMN 2.0 —  предназначена для бизнес-пользователей и содержит подгруппу объектов BPMN 2.0, годных для конструирования и анализа бизнес-процессов
  • Исполняемая BPMN 2.0 — предназначена для разработчиков технических моделей.
Ниже приводится описание основных графических элементов, которые позволяют построить законченную схему бизнес-процесса. Перечень всех графических элементов - в документации.

Условно, подчеркну, условно разобьем описание элементов на шаги. Эти шаги примерно будут описывать порядок осмысления и формализации бизнес-процесса.

Первый шаг при построении диаграмм - определение пулов и дорожек.

Второй шаг - определение стартового и, желательно, конечного события.

Третий шаг - опеределение задач.
Бизнес-правила в большинстве случае определяются в рамках задач.

В описательной BPMN 2.0 доступны различные типы задач. Из основных - следующие:
  • Cтандартная задача.
  • Сервисная задача.
  • Пользовательская задача.
  • Действия вызова. Эта задача описывает целый процесс, который может вызываться повторно, а также использоваться в разных процессах.
  • Подпроцесс. Показывает, что данное действие состоит из подзадач и на схеме эти задачи "свернуты".
Четвертый шаг, который выполняется параллельно с третьим, - определение шлюзов.
Шлюзы контролируют поток операций процесса и могут разделять или объединять поток, чтобы показать, что требуется несколько решений или одновременных действий.
В описательной BPMN 2.0 доступно два вида шлюзов.

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

В описательной BPMN 2.0 доступны свои типы данных, и испольнительной - свои.
Исполнителная часть BPMN гораздо сложнее описательной.
В определенной степени эта сложность уже проявляется на постере BPMN. Это постер достаточно "известный" и может быть найден в интернете.

четверг, 21 мая 2020 г.

Бизнес-логика

Бизнес-логика кодирует бизнес-правила, которые определяют, каким образом данные могут быть созданы, сохранены и изменены.

Бизнес логика:
  • Предписывает, как бизнес-объекты взаимодействуют друг с другом.
  • Обеспечивает применение маршрутов и методов доступа и обновления бизнес-объектов.
Бизнес-правила же являются логическими моделями (высказываниями) о реальных бизнес-объектах.

Бизнес логика включает в себя рабочие процессы, которые являются упорядоченными задачами передачи документов или данных от одного участника (человека или системы программного обеспечения) другому.

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

Все, что является процессом или процедурой, является бизнес-логикой, а все, что не является ни процессом, ни процедурой, является бизнес-правилом.

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

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

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

Это реализуется посредством многоступенчатой архитектуры, - путем создания слоев и уровней. Каждый слой отделен от других слоев, и каждый слой имеет минимальное количество кода в других слоях.

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

воскресенье, 17 мая 2020 г.

Бизнес-правила

Бизнес-правила описывают операции, определения и ограничения, которые применимы в организации. Бизнес-правила могут применяться к людям, процессам, корпоративному поведению, к вычислительным системам. 

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

Бизнес-правило может быть структурировано так:

                   Когда                           <условие (А)> 
                   Тогда                           <true> 
                   В противном случае <false>

То есть, на выходе бизнес-правила булевое значение: истина или ложь.

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

Пример бизнес-правила. 
"Проверка кредита не должна выполняться для постоянных клиентов".
Или в формальной записи:
Нужно ли выполнять проверку кредита: Если клиент не относится к категории постоянных клиентов, то "TRUE", иначе "FALSE".

Бизнес-правила могут быть формальными или неформальными, задокументированными или н задокументированными.

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

Организации могут заблаговременно описать свои методы и способы ведения бизнеса и создать базу данных бизнес-правил. Хотя эта деятельность может быть полезной, но она может также быть дорогой и трудоемкой. И последнее - серьезное препятствия для документирования бизнес-правил.

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

Осознав недостатки практики сбора бизнес правила, эксперты по бизнес-анализу выдвинули методологию создания бизнес правил ((https://en.wikipedia.org/wiki/Business_rules_approach)

Кое-что о методологии создания бизнес-правил

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

В рамках данной методологии фигурируют следующие концептуальные объекты:
  • Типы бизнес-правил.
  • Категории бизнес-правил.
  • Отношения бизнес-правил.
Типы бизнес-правил
Для определения типов бизнес-правил нужно учитывать несколько предпосылок (утверждений):
  • Структурные предположения. Описания структуры, где и посредством которой регистрируются факты о предприятии, которые в последствии используются для принятия решений.
  • Предположения о деятельности. Ограничения и условия, которым подчиняется или контролируется бизнес.
  • Деривация или извлечение знаний. Дополнительные знания, которые вытекают из первичных знаний о бизнесе.
Принимая во внимания эти предпосылки, бизнес-правила можно разделить на:
  • Правила координации. Правила, обеспечивающие деятельность без непроизводительных остановок.
  • Правила квалификации/дисквалификации. Эти правила используются для определения того, что должно быть вовлечено в деятельность, а что нет. Это может быть тождественно работе фильтров.
  • Правила принятия решения.
Категории
Бизнес-правила подразделяется на одну из четырех категорий:
  • Определения бизнес-терминов
Бизнес-правила выражаются посредством языка. Определение термина само по себе является бизнес-правилом, которое описывает, как люди думают и как говорят о вещах. Таким образом, определение термина устанавливает категорию бизнес-правила. Термины традиционно документируются в глоссарии или описываются как объекты в соответсвующей концептуальной модели бизнес-процесса.
 
  • Отношения фактов
Характер или структура деятельности организации могут быть описаны фактами, которые соотносят термины и факты друг с другом.
Например, сказать, что клиент может сделать заказ, это НЕ бизнес-правило, а факт. 
Факты могут быть задокументированы как предложения на естественном языке. Могут быть представлены графическими моделями как отношения, атрибуты и структуры обобщения.
 
  • Ограничения (также называемые «действиями»)
Каждое предприятие каким-то образом ограничивает поведение, и это тесно связано с ограничениями того, какие данные могут обновляться или не обновляться. Предотвращение создания записи во многих случаях препятствует выполнению действия.
 
  • Правила преобразования знаний
Бизнес-правила (включая законы природы) определяют, как знания в одной форме могут быть преобразованы в другие знания, возможно, в другую форму.

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

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

Формальные спецификации описания бизнес-правил

Бизнес-правила могут быть выражены с использованием подходов моделирования, таких как
  • унифицированный язык моделирования (UML), 
  • язык выполнения бизнес-процессов (BPEL), 
  • нотация моделирования бизнес-процессов (BPMN), 
  • модель принятия решений и нотация (DMN), 
  • семантика бизнес-словаря и Деловые правила (SBVR),
  • нотация Z.
Бизнес-правила, закодированные в компьютерном коде в операционной программе, называются бизнес-логикой.

Программные системы управления бизнес-правилами

BRMS или система управления бизнес-правилами включает в себя политики, требования и условные операторы, которые используются для определения действий, выполняемых в приложениях и системах.

BRMS включает, как минимум::
  • Репозиторий, предназначенный для ведения логики бизнес-правил, и соответственно, логики принятия решений.
  • Инструменты, позволяющие как техническим разработчикам, так и бизнес-экспертам определять бизнес-правила и управлят ими.
  • Среду выполнения, позволяющая приложениям вызывать логику принятия решений, управляемую BRMS, а также выполнять бизнес-правила.
Стоит упомянуть от встроенной в продукты SAP системы управления бизнес-правила - BRFplus. Что в некоторых случаях существенно облегачает кастомизацию конкретного решения.

четверг, 12 сентября 2019 г.

Решение проблем

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

Для стоит помнить о шести правилах:

  • Персонал должен знать, чем занимаются остальные сотрудники.
  • Расширить полномочия посредников.
  • Расширить полномочия сотрудников (дать людям больше власти).
  • Найти "повод" и "побудительные причины" для сотрудничества.
  • Заставить сотрудников думать о будущем.
  • Возложить ответственность за сбои на тех, кто не желает сотрудничать.
А также помнить о предостережения или запретах:
  • Не утверждайте новые процедуры и не вводите лишние уровни управления без крайней необходимости. (Добавлять или сохранять ненужное также плохо, как и не делать необходимого).
  • Не ищите плохих результатов в отношении людей к делу или в их образе мыслей. (Иначе - Вы не видите проблему в целом. Нужно обратить внимания на задачи, которые решают люди; на ресурсы, которыми они располагают; на трудности, с которыми они сталкиваются).
  • Не берите на себя все решения - оставьте другим.
  • Не полагайтесь на материальные стимулы - могут неприятные побочные эффекты.
  • Не пытайтесь количественно оценивать сотрудничество, полагайтесь на мнения.
По материалам. Ив Морьё. Что делать, чтобы проблемы решались без вас. Harvard Business Review. 12.2011.

В развитие этого пригодятся принципы производственной системы Toyota.

1. Постоянно минимизируйте потери.
Люди не подозревают, сколько времени можно сэкономить при правильной организации рабочего процесса.
Используемые приемы:
  • Задавайте пять вопросов примерно такого вида: Зачем? Почему? Для чего?
  • Выявляйте даже самые мелкие потери.
  • Периодически пересматривайте суть работы каждого сотрудника.
2. Четко формулируйте задачи. Значительную часть работы можно описать, если описано, то можно совершенствовать.
Используемые приемы:
  • Выявите повторяющие элементы и формулизуйте их.
  • Не пытайтесь описать все и сразу.
  • Оперируйте фактами, иначе вам не поверят.
  • Постоянно анализируйте виды работ, которые пока не поддаются формализации.
3. Наладьте обмен информацией.
Приемы:
  • Определите, кто, когда, как часто и какую информацию должно предоставлять.
  • Добейтесь единого понимания терминов, понятий и содержания информации.
  • Решайте споры, опираясь на факты.
4. Следуйте методу научного эксперимента, чтобы оперативно устранить проблемы.
Приемы:
  • Обнаруженную проблему должен устранить ее виновник (в идеале).
  • Решайте проблем в месте их возникновения.
  • Решайте проблемы по "горячим следам".
5. Организуйте процесс непрерывного улучшения. Тщательно планируйте переход к новому.
Приемы:
  • Начните с малого.
  • Записывайте наблюдения по ходу "диффузии нового".
  • Постоянно ищите новые методы.
  • Помните - новое годится не для всего.
6. Пропагандировать новую систему обязано руководство.
Приемы:
  • Руководители проектов, менеджеры должны обучать и мотивировать подчиненных.
  • Высшее руководство должно обеспечивать и поддерживать стратегическую перспективу.

среда, 7 августа 2019 г.

Принцип документационного обеспечения

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

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

  1. Аутентичность. Обеспечивается политикой и процедурами, которые контролируют создание, получение, передачу, хранение документов, а также распоряжение документами с гарантиями того, что создатели документов уполномочены и идентифицированы, а документы защищены от несанционированного добавления, стирания, переделки, использования и утаивания.
  2. Достоверность: полнота, своевременность, актуальность (отражение всех изменений).
  3. Целостность. Любые санкционированные аннотации и добавления к документу или стирание в документе должны быть явно указаны и прослеживаемы. Обеспечивается мерами контроля и наблюдения за доступом и верификацией пользователей, санкционированным уничтожением и охраной документов.
  4. Эксплуатационная готовность. Каждый документ должен быть найден, предоставлен и интерпретирован, должно быть всегда известно его местонахождение. Для сложных докуметов должны быть явно указаны конекстуальные взаимосвязи документов, должны иметься возможность определить документ в контексте более широких деловых операций и функций.
  5. Соответствие. Содержание и форма документа должны соответствовать требованиям, предъявляемых к данному типу документов.
  6. Своевременность. Каждый документ должен быть создан и актуален в течение определенного периода.

пятница, 26 июля 2019 г.

5 советов по расстановке приоритетов требований к ERP и вообще автоматизации

На основании заметки
 Tips for Prioritizing ERP Requirements by Panorama Consulting Group | Jun 17, 2019

Данные советы применимы не только в случае выбора новой ERP или модернизации или для различного вида доработок. В узком смысле, в случае когда выявлены узкие места, громоздкие и нудные работы, функциональные разрывы, все нудное и рутинное, что может быть поручено компьютеру встает задача сформировать документ с рабочим названием "Функциональные требования...".
Хорошо, если все желаемое можно реализовать. Но так не бывает. Требования могут быть противоречивыми, а ресурсы ограниченными и нужно выбирать. Выбор можно сделать случайным, а можно придать выбору некоторую степень рациональности и обоснованности. Приоритизация - один из инструментов обоснования выбора. Но нужно иметь введу, что приоритеты в конечном счете утверждает человек. Это может лицо, принимающее решение, или лидер, формальный или неформальный. А раз человек - то мы имеем субъективное решение, и важно, чтобы оно было правильным.

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

1. Уточните цели Проекта, Объем проекта, Периметр проекта.

Есть известная проблема, описываемая как треугольник в управлении проектами.
В частности, вот так описан треугольник Треугольник управления проектами

''Сделаем хорошо, быстро, дешево. Выберите из этих трех условий два''.
Инженеры уже десятки лет говорят это руководителям проектов.
Если сформулировать эту мысль немного иначе, каждый проект представляет собой треугольник, в котором сбалансированы время, деньги и область охвата, — изменить один из факторов, не затронув хотя бы один из других, невозможно. Задача руководителя проекта — следить за тем, чтобы треугольник не распался.
Но как? Когда возникает проблема, сначала определите ее место в треугольнике проекта: в чем дело — во времени (расписание), деньгах (бюджет) или области охвата? Во-вторых, выясните, какие стороны треугольника вы можете изменить, а какие зафиксированы. В-третьих, скорректируйте факторы, которые помогут устранить проблему и оптимизировать проект. В-четвертых, сдайте проект и отпразднуйте его завершение!
Вы должны четко определить бизнес-цель проекта и определить элементы, которые определенно выходят за рамки проектного треугольника.

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

2. Определите базовые бизнес-процессы

Определение бизнес-процессов поможет вам определить масштаб проекта. Это поможет составить список минимальных требований, необходимых для поддержания бизнеса.

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

3. Совершенствуйте свои процессы

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

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

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

4. Выполните Fit-Gap анализ.

Fit-Gap анализ поможет выполнить анализ разрывов и пробелов. Это поможет вам определить, где новая система будет соответствовать требованиям вашей компании, а где - нет.

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

Следует помнить, что требования к устранению gap-ов (разрывов) не должны перекрывать функциональные требования и в процессе расстановки приоритетов должны рассматриваться в конце.

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

  • Если не устранить разрыв, как это отразиться на бизнесе?
  • Требуются ли для устранения разрыва дополнительные трудовые ресурсы?
  • Будут ли монетарные потери или упущенная выгода, если не устранить разрыв?
  • Как разрыв влияет на удовлетворенность клиентов?
  • Как разрыв влияет на соблюдение требованний государства и иных регулирующих организаций и союзов?
  • Повлияет ли устранение разрыва на график проекта?
  • Сколько времени и иных ресурсов требуется на устранение разрыва?

Основываясь на этом анализе, можно оценить выгоды и затраты устранения разрыва и определить - стоит ли браться за устранение разрыва. А также обосновывать - почему разрыв не устранен, если на этом будут настаивать при сдаче проекта.

5. Классифицируйте бизнес-требования

После того, как требования собраны, разделите их на три класса:

  • Обязательно к исполнению. Критически важные требования.
  • Повышает стоимость бизнеса.
  • Приятно иметь.

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

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

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