понедельник, 29 июня 2015 г.

Что должен включать в себя бизнес-кейс?



Странно, но мне не удалось найти в интернете толковый список того, что же должен включать в себя бизнес-кейс для обоснования и отслеживания целесообразности инвестиции. Попробую восполнить этот пробел вольным переводом из CGEIT Review Manual 2015 by ISACA

Ситуация непростая, так как даже статья про Business case на Википедии на русском уже превращается в Технико-экономическое обоснование, что, конечно же не совсем одно и то же.

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

Итак, бизнес-кейс, как минимум, должен включать в себя:
  • Причину (основание) для инвестиции - это возможность, которую можно реализовать, или проблему, которую нужно решить
  • Рекомендуемый способ решения (подход) - включая альтернативные варианты, и почему этот лучший
  • Целевые преимущества для бизнеса - связь с бизнес-стратегией, как эти преимущества будут измеряться и кто конкретно будет ответственный за их реализацию 
  • Начальные вложения и затраты по ходу проекта - ИТ и бизнес расходы по ходу реализации
  • Изменения в бизнесе - какие изменения потребуется провести в бизнес-процессах и инвестиции которые потребуются на эти изменения
  • Риски, присущие этому подходу - включая риски достижения необходимых целей, а также риски, насколько организация будет в состоянии потом поддерживать эти изменения чтобы получать прибыль.
  • Руководство, присущее этому подходу - как инвестиция будет отслеживаться в течение всего ее жизненного цикла, какие метрики будут использоваться и кто в конечном итоге будет нести ответственность за достижение необходимых выгод
Бизнес-кейс план может включать в себя следующие планы:
  • Детальный план всей программы (включая отдельные планы проектов)
  • Ресурсный план
  • Финансовый план
  • План реализации преимуществ для бизнеса
  • План изменений, в том числе и организационных
  • План управления рисками (в том числе и реестр рисков)


Оригинал:

At minimum, the business case should include the following:
• The reason for the investment—The opportunity or
problem that the investment is intended to address
• The recommended solution/approach—Including
alternatives considered and proposed timetable
• The business benefits targeted—Their alignment with
business strategy, how they will be measured and who in the
business functions will be responsible for securing them
• The initial investment and ongoing costs—Both the IT and
business costs of operating in the changed way
• The business changes—Needed to create and realize
sustained additional value and the investments needed to
make the changes
• The risk inherent in the approach—Including delivery risk
(the risk of not being able to deliver required capabilities)
and benefit risk (the risk of the organization not being able to
make and sustain the changes required to use the capabilities
to create and sustain value)
• The governance approach for the investment—How the
investment and value creation will be monitored throughout
the economic life cycle, the metrics to be used and who
will be ultimately accountable for the successful creation of
optimal value
The business case should, as appropriate, include high-level
summaries of and links to:

• The detailed program plan (including individual project plans)
• The resourcing plan
• The financial plan
• The benefits realization plan (including the benefits register)
• The (organizational) change management plan
• The risk management plan (including the risk register)

вторник, 16 июня 2015 г.

Матричная vs иерархическая структура управления

В последнее время на вопрос "почему у меня 2 начальника?" стало модным отвечать "это потому, что у нас матричная структура управления". Давайте попытаемся разобраться, что же такое матричная структура управления и чем она отличается от классической, иерархической структуры.

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

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


Здесь строчки - это процессы, а столбцы - это сотрудники, которые принимают участие в работе процесса. Обычно определяют 4 вида участия в процессе:

A - Accountable. Утверждающая сторона - лицо, несущее конечную ответственность за процесс. Отвечает на следующий вопрос: "Кто отвечает за успешное решение задачи?"

R - Responsible. Ответственная сторона. Тот, кто должен обеспечить успешное выполнение деятельности. Отвечает на следующий вопрос: "Кто занимается выполнением задания?". Это роли, выполняющие основную часть перечисленных операционных действий и создающие необходимый результат.

C - Consulted. Консультирующая сторона. Те, чье мнение важно при выполнении деятельности (подразумевается обмен мнениями). Отвечает на следующий вопрос: «Кто предоставляет информацию на входе в деятельность?». Ключевые роли, предоставляющие информацию. В матрице RACI, ответственные (Responsible) и утверждающие (Accountable) лица решают, использовать ли другие подразделения предприятия и внешних партнеров в качестве источников информации. Тем не менее, информацию, которой владеют указанные контрагенты, следует учитывать, и при необходимости, проводить эскалацию, включая информирование владельца процесса или управляющего комитета.

I - Informed. Информируемая сторона. Те, кого следует информировать о ходе выполнения работ (подразумевается односторонний канал коммуникаций). Отвечает на вопрос: «Кто получает информацию?». Это роли, которых информируют о достижениях или о результатах исполнения задач. Утверждающее лицо (Accountable) также всегда должно получать корректную информацию, чтобы осуществлять надзор за исполнением задач, равно как
и ответственные за работу по исполнению лица.

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

В рамках же каждого процесса есть регламент, и, единственный ответственный за процесс в целом (Accountable), он и является "боссом" в рамках данного процесса.

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

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