Мастерская бизнес-анализа

Разные разные пользователи (продолжение)

18.12.2009 at 11:15 4 комментария

А теперь на дворе год 2003

Меня пригласили на уже начатый проект. Пользователи –  финансовая организация довольно высокого уровня (отвечает за бюджет  области).

Этап разработки технического задания завершен, денежки все получены и естественно потрачены. Идет стадия  разработки, и уже пришло время эту разработку закончить и сдать. И уже десант разработчиков и аналитиков высадили прямо в офис Заказчика (благо все происходит в одном городе).   Ан до выхода на руководство для сдачи Системы и подписания актов дело никак не доходит.

Начинаю разбираться. И вот какие характеристики этого проекта:

1. Проект выполняют  внешние разработчики.
2. Разработка  заказная – и с  точки зрения пользователя,  и для разработчика.
3. Система должна была быть разработана для всей организации, но под конкретную функцию. Причем в реализации этой функции участвуют как значительная часть работников собственно финансовой организации, так и сотрудники других организаций (на отдельных этапах) и их много.
4. Инициатором разработки АС являлись сотрудники отдела АСУ  финансовой организации.
5. В этой организации на тот момент разве что курьеры и уборщицы не сидели за компьютерами – а так все были охвачены. Использовалось несколько разных информационных систем, и очень активно задействованы возможности MS Office.

Теперь в повествовательном ключе

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

К 2001г учетные функции и функции исполнения бюджета (а для финансистов «исполнение бюджета» — это как бы «производство», оперативное управление) уже так или иначе автоматизированы, а вот планирование осуществляется в EXCELe.

И уже сотрудники отдела АСУ выжали из этого EXCEL-я все, что можно, обеспечивая поддержку хотя бы иллюзии коллективной работы.  Но это привело к тому, что процесс частично переместился из отделов финансовых, в отдел АСУ.

А планирование бюджета – это процесс согласования, достижения компромисса между большим количеством участников. Причем в определенный временной промежуток этот процесс сильно спрессован во времени.

Приходится работать и поздно вечером, и ночью, просчитывая различные (часто чисто «политические») варианты. С учетом особенностей процесса, и сотрудники отдела АСУ проводят эти ночи на работе. Причем, часто надо не только отдельные перерасчеты сделать, но и всеь бюджет со всеми его взаимосвязями в готов виде (на бумаге) представить. А еще, очень часто, после всех обсуждений, надо вариант бюджета откатить назад (потому что финансисты все равно его лучше сверстали), но с учетом отдельных принятых изменений. Вообщем, задача при больших объемах и супертребованиях по оперативности для  EXCEL-а стала неподъемной, а сотрудникам отдела АСУ все это сильно не нравилось.

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

Что было в начале

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

Но вот когда пришло время сдавать первые модули системы, надо же было их представить финансистам, причем если не на уровне первого руководителя, то хотя бы на уровне зама. Но у разработчика – как выяснилось – ни один специалист – ни руководитель, ни аналитик (к тому времени он был один – требования же уже собрали, описали, разработчикам сдали – чего еще…) говорить на нормальном языке пользователя – финансиста (здесь вот приходится каждый раз уточнять) не мог.

Вот в этот момент меня и пригласили. А я в области финансов до того никогда не работала (все-таки машиностроение и здравоохранение от этого были очень далеко), но опыт аналитика и экономическое образование помогли мне погрузиться в предметную область достаточно быстро. По крайней мере, через месяц уже удалось провести совещание с пользователями на нужном уровне и объяснить им – что же делает та Система, которую для них разработали. Более того, через несколько месяцев Систему начали реально эксплуатировать и бюджет следующего — 2004года – был спланирован с ее использованием (Разработали-то систему совсем  не плохо).

Что пришлось предпринять

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

Сначала, аналитик ходил к тем из конечных пользователей, кто был наиболее лоялен к проекту (всегда есть кто-то, кому более чем другим интересно всем новым заниматься).

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

То есть, в данном случае, то, что процесс проектирования и взаимодействия с пользователями не удалось с самого начала «выстроить по науке», не пошло проекту на пользу. НО! Если бы разработчики поставили процесс во главу угла, они бы этот проект потеряли (именно потому, что инициирован он был АСУшниками).

Что удалось предпринять: мы  — компания разработчик – погрузились в предметную область по уши, установили контакты с вышестоящими финансовыми структурами и с несколькими консалтинговыми фирмами (одной было бы мало, чтобы нас не обвинили в лоббировании интересов именно этой фирмы в части методологии), стали участниками  совещаний и конференций по вопросам бюджетной реформы (а какая-то реформа у нас всегда есть). Это позволило нам придти к пользователям нужного нам уровня не с вопросами, а со знаниями, идеями, конкретными  предложениями, которые в свою очередь реализовывались  в системе вариантами настройки. И вот тогда они увидели Систему, оценили ее и нас, и начали  с нами разговаривать по-другому.

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

Вывод у меня такой

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

Entry filed under: Пользователь и ИТ-специалист.