Определение того, что в конечном счете представляет собой предмет «Фупана»

Финансовая компания планировала в течение года запустить комплексную систему обработки данных оперативной деятельности и перенести бумажный документооборот в iТ-систему, чтобы повысить эффективность работы, сократить количество бизнес-ошибок и объединить «информационные острова»[41] предприятия.

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

В ходе расследования, проводимого совместно с проектной командой, мы обнаружили, что команда из отдела информационных технологий и команда поставщика услуг проводила «Фупан» на каждом этапе реализации проекта. Из сохранившихся документов проведенных «Фупанов» мы смогли упорядочить все то множество проблем, которые возникли и были решены в ходе проекта. Руководитель проектной группы поднял вопрос: «Достаточно ли будет выбрать ключевые моменты из вышеизложенных проблем и обсудить их с участниками во время фупан-совещания?» По его мнению, не было необходимости и возможности проводить полный «Фупан» проекта длительностью в 18 месяцев. В конце концов, коллеги из разных отделов, принимающие участие в совещании, имели разную степень вовлеченности в проект, к тому же не были знакомы со многими деталями процесса разработки проекта и не обязаны быть в курсе всех этих моментов. Так что же нам следует исследовать во время фупан-совещания? В ответ мы разъяснили, что каждый участник должен проводить «Фупан», к тому же предметом «Фупана» должны выступать ключевые моменты проекта.

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

На последнем подготовительном собрании (последнем, потому что нам удалось найти ответ) мы изменили угол зрения – с «разработчика» на «пользователя». Поскольку все коллеги, присутствующие на собрании, также были пользователями системы, на интервью мы выявили аспекты, которыми были недовольны сотрудники. Главной проблемой стала неспособность системы выполнять бизнес-операции. После ее запуска разработчики вносили изменения по мере поступления запросов от сотрудников.

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

Для «Фупана» это прекрасная новость, ведь чем больше проблема угнетает людей, тем тщательнее стоит проводить ее «Фупан». После обсуждения на совещании мы единогласно решили в этот раз провести «Фупан» запроса на изменения в системе, чтобы использовать этот аспект для выявления пунктов, которые подлежат рассмотрению на протяжении всего проекта. Таким образом возможно удовлетворить условия «проведение "Фупана" всеми участниками команды» и «полезность "Фупана"».

Далее последовал вопрос: «Что следует рассматривать в процессе "Фупана" запроса на изменения?»

Проектная команда упорядочила более 2 000 записей из системных журналов касательно запросов на изменения и разделила их на одинадцать основных категорий. Среди этих запросов 70% относились к первым трем категориям. Далее команда выбрала по два типичных случая из трех категорий, организовав их в соответствии с единым шаблоном: описание ситуации до запроса на изменение, моделирование ситуации до запроса на изменение, причина запроса на изменение, описание ситуации после изменения, моделирование ситуации после изменения, оценка эффективности изменения. Во время фупан-совещания каждая группа получила отдельный кейс для анализа. Это стало этапом «упорядочение процесса» в форме предварительного рассмотрения. Далее участники обсуждали кейсы, последовательно проходя все шаги модели «Фупана». На основе полученных результатов и ключевых идей был разработан общий план проведения совещания. На этом фупан-совещании участники провели углубленное обсуждение шести случаев запроса на изменения и получили большое количество содержательных инсайтов в ходе обобщения.

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

Это пример проектного «Фупана», когда, найдя одно главное звено, можно понять весь процесс целиком. Такой подход особенно полезен для долгих проектов с большим количеством участников. В нашем случае этим звеном стал запрос на изменения, который связал пользователей и разработчиков. Благодаря функциям записи в IT-системе и привычке команды все фиксировать удалось создать основу для плана фупан-совещания.

Каждый проект уникален, поэтому нет единого способа определить, что станет главным предметом «Фупана». Главное – внимательно разобраться в ситуации и найти настоящую причину проблемы.