Photo Credit: Tambako the Jaguar via Compfight cc

Photo Credit: Tambako the Jaguar via Compfight cc

Эта идея крутилась в голове очень давно, но ее было сложно запаковать в слова. Такое бывает.

Максим Смирнов сделал это за меня 🙂 Цитирую:

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

[info]

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

[/info]

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

Так что нужно сделать, чтобы упростить ландшафт бизнес-процессов?

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

Как сказал? 🙂 Наверное мало кто понял, а те кто понял — скорее всего поняли не так.

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

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

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

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

И вот тут начинается поиск решений… личной мой поиск привел меня к идеи Элияху Голдратта, под названием «критическая цепь». Она описана в одноименной книге (найти можно у куба).

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

Так вот, в каждой системе управления проектами есть такое слабое звено — это тот сотрудник или отдел, об который спотыкаются все проекты.

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

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

Потому сами тормоза — это не проблема. Проблема — это когда 2 или 3 отдела, в трех или четырех проектах, упираются в медленный отдел ИТ, и часть этих проектов начинает буксовать. Какие ощущения ловят руководители этих проектов? Правильно… у меня есть срок проекта, и этот срок скоро вылетит в трубу, а причина не в том что я плохой руководитель, а в том что отдел ИТ уже на месяц задерживает обещанный результат, или того хуже — вообще не может назвать сроков, рассказывая сказки: о том что ИТ — это типа творческая область, тут нельзя ничего планировать и гарантировать, и вообще мы перегружены, вон иди с теми 3-мя руководителями разбирайся, они уже с генеральным цапаются за то кому отдать приоритет…

Теперь представьте… каким инструментом можно решить эту проблему? Да, методически, решение этой проблемы описана в книге «Критическая цепь», но для ее решения нужен инструментарий. MS Project? Мегаплан? Basecamp? — отдыхают в сторонке.

Для того, чтобы этот метод реализовать на практике, нужно чтобы данные между процессом «управление проектами» и процессом «разработка ПО» — были тесно связаны и позволяли строить Диаграмму Ганта или сетевой график со всеми взаимосвязями.

А вы пробовали загнать разработчиков в Basecamp или Мегаплан? Там же нет механизмов планирования разработки, бэклога и других атрибутов управления в этом процессе. Таким образом, в этих системах нет данных из двух процессов. Либо только из одного, либо из второго. Извините.

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

Так… ну проблему вроде как разложили… перейдем к решению?

Представьте приложение, которое с одинаковым успехом позволяет решать как задачи проектных руководителей, так и рядовых программистов… вы думаете фантастика? А вот и нет 🙂 Я даже могу назвать 2 ИТ-инструмента, которые это позволяют делать. Причем один из них — старше любого из нас, а второй — CasePress.

CasePress — соответствует идеологии Adaptive Case Managment, а суть этой идеологии как раз и заключается в умении подстраиваться под любые процессы.

Будь то управление проектами или разработкой ПО — без разницы.

Да, я писал что их 2. Угадайте второй? Суть загадки и подсказки есть тут.

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

Пусть не на 100%, но все же скоорденированность отделов и руководителей проектов при таком решении — значительно улучшается. Именно за счет того, что ACM как архитектура и CasePress как приложение позволяет организовать обмен данными между разными процессами.

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