Построение решения

Александр Дублин

Внедрение SAP и техники McKinsey


Александр Дублин 27 мая 2011, 10:38

                                                                                                             «Решение задач – ваша работа»

                                                                                                                 (Девиз McKinsey)

РЕШЕНИЕ ПО MC KINSEY И НЕ ТОЛЬКО.

Три столпа решения

По методологии McKinsey проектное решение должно:

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

Предварительное обследование. Факты - ваши друзья.

Процесс решения проблем всегда начинается с рассмотрения фактов. Для SAP-консультанта это - изучение бизнес-процессов ключевых пользователей и выявления проблем их «улучшения». Все множество фактов, собранное участниками команды, должно анализироваться с целью подтвер-ждения или опровержения «гипотезы», представляемой текущей настройкой системы. Факты в сочетании с шестым чувством ключевых пользователей – кирпичики, которыми вы выложите дорогу к эффективному решению. Многие ключевые пользователи боятся фактов. Может быть они считают, что если не будут обращать на них внимания, они «исчезнут «чудом» Это не так! Вы не должны бояться фактов. Охотьтесь за ними, используйте их, но не бойтесь. Только на основе фактов достигается взаимопонимание и возникает доверие.

Техника «MECE»

«Не подгоняйте факты под начальное решение»

(Правило McKinsey)

После того как сопоставлены факты и «начальный проект» не превращайте весь процесс вне-дрения в упражнение, направленное на доказательство правильности первоначального решения. Стоит потрудиться над группировкой проблем по принципам MECE (это аббревиатура от «взаимно исключающими, совместно исчерпывающие – Mutually Exclusive, Collectively Exhaustive). Вы долж-ны полностью освободиться от путаницы и повторений. Расположите аспекты выявленных проблем последовательно именно один за другим. Рекомендуется структура:

«Решайте проблему на первой же встрече – начальное решение»

(Правило McKinSey)

Отправная гипотеза – третий столп для процесса решения. Этот столп можно представить со-стоящим из трех частей (классическая колонна):

  • Первая группа – решаемые проблемы (полезность решения очевидна ключевому поль-зователю);
  • Вторая группа - дополнительные проблемы (для их решения необходимо дополнитель-ное соглашение с Заказчиком);
  • Третья группа - проблемы исключаемые (затраты на решение не «влезают» в Scope).
  • Определение начального решения (гипотезы);
  • Развитие начального решения;
  • Проверка начальной гипотезы.

Определение начального решения

Цель - получить определённые очертания SCOPE, Следует составить список проблем в технике MECE. Если на встречах с ключевым пользователем вы решите рассмотреть ещё один аспект внедрения или проблему, добивайтесь четкого разделения проблем по соответствующим группам и соблюдения правил MESE. Список основных (первого уровня) проблем не должен быть слишком большим. Рекомендуем 5-7 пунктов.

Развитие начального решения

Цель - структуризация проблем и заданий. Для этого необходимо определить так называемые ключевые факторы решения проблем. Это даст возможность определить список заданий (настроек системы). Чтобы сделать следующий шаг вы должны все задачи первого уровня разбить на более мелкие задачи, соблюдая правила MESE при пополнении списка заданий соответственно «извлекаемым» проблемам пользователя, развитым до явных потребностей.

Проверка начального решения

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

ЛОГИЧЕСКИЕ СТРУКТУРЫ ПРОБЛЕМ И РЕШЕНИЙ

Логическое дерево проблемы

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

Пример. Компания XXX хочет увеличить прибыль (эффективность бизнеса) (ЭБ) с помощью повышения эффективности бизнес процессов: «закупки сырья» (ЗС) и «учета платежей» (УП) (первый уровень логического дерева).

Разделив компоненты первого уровня соответственно на «прямые закупки»(ПЗ) и «закупки через посредников»(ЗП); и на «учет платежей поставщикам» (УПП) и «учет расчетов с посредниками» (УРП), получим следующий результат структурирования проблемы на два уровня иерархии.(рис 1)

Рис. 1 Уровни иерархии

Логическая картина решения

Внедрение серьёзного решения всегда представляет собой проект. Эффективный способ построить логическую картину реализации решения, как проекта – определить последовательность проектных работ, расположенных в логическом порядке. Логика расположения (движения проекта) определяется вопросом (что необходимо, чтобы двигаться дальше, достижение какого промежуточного результата необходимо?). Достижение необходимого результата рассматривается как ключевое событие (контрольная точка). Каждое ключевое событие определяется последовательностью вспомогательных событий, более низкого уровня иерархии. Пример иерархической схемы контрольных точек процесса реализации решения приведен на рис.2.

Рис. 2 Иерархическоя схема контрольных точек процесса реализации решения

← Назад