Оценка ограничений решения

Записаться

Здравствуйте. Мы продолжаем изучать область знания по бизнес-анализу Оценка решения. Мы уже с вами рассмотрели задачи 8.1 Оценка производительности решения, задачи 8.2 Анализ показателей производительности решения. Мы плотно рассмотрели вопросы, касающиеся показателей производительности. Какие они должны быть, откуда брать данные и провели анализ этих показателей.

Теперь же давайте посмотрим на решение немножко с другой стороны. У любого решения есть какие-то ограничения в жизни, и вы с этим регулярно сталкиваетесь. Решения могут быть совершенно разного свойства. Они могут быть чаще всего технические - используется какой-то устаревший подход или используется не гибкий подход к решению – это технический аспект. Можно рассматривать ограничения с организационной стороны и еще с каких-то сторон. Задача 8.3 - это оценка ограничения самого решения, как бы отдельно взятого решения. Под словом решение мы можем подразумевать программное обеспечение, новый вариант бизнес-процесса, новый вариант оргструктуры и так далее. У каждого из этих вариантов есть какие-то ограничения. BABOK предлагает выделить в отдельную активность выявление этих ограничений решения и в дальнейшем предприятие мер по тому, чтобы снять эти ограничения.

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

Давайте рассмотрим окружении задачи. Итак, на вход задачи 8.3 «оценка ограничений» идет результат задачи 8.2. Задача 8.2, соответственно, потребляет результат задачи 8.1. Получается такая цепочка 8.1 - 8.2 - 8.3, - эти задачи между собой связаны и должны выполняться последовательно. У нас есть с вами анализ показателей и есть какое-то решение - это необходимое условие для того чтобы оценить ограничение. Достаточно трудно оценивать ограничения, но фактически только на бумаге необходимо какое-то решение. Оно должно как-то функционировать, чтобы можно было понять, где же эти ограничения. У него необходимо учитывать стратегии изменений, результат анализа рисков и границы решения, поскольку, при оценке ограничений необходимо понимать, что входит в решение и что не входит в решение. Результатом выполнения задачи 8.3 является ограничения решения, сформулированные в том или ином виде.

Давайте попробуем подойти к вопросу – «а что же можно выделить как элементы работы с ограничениями?». BABOK рекомендует определить внутренние зависимости решения. Возможно наше решение состоит из каких-то компонентов и возможны какие то внутренние зависимости решения - связь модулей между собой, последовательность выполнения операций, это может в определенном контексте являться ограничением. Мы смотрим и определяем какие-то внутренние зависимости этого решения. BABOK не дает никаких конкретных примеров или рекомендации. Он просто как система, пытается подойти к вопросу о том, как надо оценивать ограничение. То есть выявить какие-то внутренние зависимости в решении. Понять в чем состоят источники проблем в нашем решении и оценить влияние этих ограничений на ценности нашего решения. Давайте подумаем, если возвращаться к нашему примеру с ERP системой. Какие ограничения могут быть у таких крупных систем? Первое что приходит на ум - это жесткость каких-то бизнес-процессов. Считается, что это является нашим внутренним ограничением. Вы должны сначала сделать «а» потом делайте «б», потом делайте «c», а переставить эти шаги местами вы не можете, настроить какие-то атрибуты вы тоже не можете - вот это решение является достаточно жестким с операционной точки зрения. Мы выявили, что в данном контексте это является ограничением.

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

Итак, кто нам может дать оценки ограничения? Представьте, что у нас есть какое-то решение. От кого могут последовать предложения что такое ограничение? Можно не знать про эти ограничения. Кто нам может сказать?

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

Давайте разберем те методы, которые BABOK рекомендуют для оценки ограничения решения.

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

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

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

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

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

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

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