Функциональное моделирование: вы подписываете стратегию жизни компании
Этап, который заказчики называют «обследованием» и хотят перетерпеть как формальность. А это единственный момент, когда вы ещё можете изменить свою будущую работу.
Заказчики называют этот этап «обследованием». И произносят так, будто речь о формальности, которую надо перетерпеть перед настоящей работой: подрядчик походит по цехам, поспрашивает, нарисует схемы - а потом начнётся то, ради чего всё затевалось.
Так вот, это и есть то, ради чего всё затевалось. На функциональном моделировании ваша будущая система проектируется целиком. Не запускается и не настраивается - проектируется. Что вы здесь одобрите, то и получите на выходе. Что здесь упустите, вылезет через восемь месяцев звонком: «почему система не делает того, что мы хотели?». Потому что этого нет в модели. А модель вы согласовали.
Ошибка, пойманная на моделировании, стоит правки одной строчки в документе. Она же на запуске стоит месяцев переделок и куска бюджета. По моему опыту соотношение примерно такое: неделя, вложенная в моделирование, экономит месяц-два на доработках. Режьте на проекте что угодно, но не режьте это.
Как выглядит пренебрежение, покажу сразу. Был у нас крупный проект, на котором заказчик потребовал проектировать будущее из логики «мы всё хотим переделать на заводе». Наши попытки подключить высшее руководство, привлечь владельцев процессов для проверки того, что проектируем - сталкивались с жёсткой позицией группы развития на предприятии. В итоге функциональную модель нарисовали - красивую, подробную, абстрактную. Большой документ, который не отражал реалий предприятия. Проект, рассчитанный на год, в итоге шёл три. Концепцию внедрения пересобирали заново по ходу внедрения, разбили на очереди, половину задуманного выкинули. И выросло это из одного: модель описывала идеальный завод из презентации, а не этот конкретный завод с его бардаком.
Что должно быть в документе, за который вы платите
Функциональная модель описывает, как ваши процессы пойдут внутри системы: что человек вводит, на основании чего, чем операция заканчивается. Про то, что происходит в информационной системе, а не про то, кто кому позвонил. Вещь упрощённая, без классических схем бизнес-процессов со стрелочками ответственности. Модель системы, а не хоровод людей вокруг неё.
Теперь как отличить рабочий документ от пустого. Признак простой, проверяется за десять минут. Откройте раздел про свой процесс. Если там перечислены все варианты, которые система в принципе умеет, плюс кусок справки из документации, а одного выработанного пути - как оно будет именно у вас - нет, то раздел не решает ничего. Вам показали каталог возможностей и оставили выбор за вами, хотя выбирать вы наняли подрядчика. Рабочая модель выбирает один путь и описывает его.
Откуда берётся рабочий документ
Из въедливости, доходящей до неудобной. Пример, который любит показывать один из наших руководителей проектов.
Пользователь говорит: хочу вести сроки годности в системе. Желание нормальное. Опытный консультант не кивает, а спрашивает: а где у вас сроки годности сейчас? - В паспортах. - Покажите паспорт. Смотрит: партия, а в ней десять разных сроков. Дальше вопрос уже на складе: вот пришла паллета, как кладовщик поймёт, какой срок он сейчас отгружает? Идут на склад. Стоят бочки, на каждой свой срок.
Значит, чтобы вести сроки годности честно, при приёмке паллету надо вскрыть и разложить бочки по срокам. Речь шла о краске, и паллеты с ней стояли друг на друге - вскрой их, и хранить разобранное физически негде. Готов к этому заказчик? Если да - отлично. Если паллета уходит в производство целиком, сроки годности мы введём, но никакого ФИФО и списания по срокам не будет: процесс на это не заточен.
Вот это и есть моделирование - поставить себя на место кладовщика. Иначе в системе появится красивая функция, которая живёт только на бумаге, а на складе её обходят стороной.
И сразу сниму ожидание идеала. Гнаться за стопроцентной достоверностью модели не надо. Все процессы предприятия за разумные деньги не описать: уйдёт год, а на выходе будет просто документ. Достоверность процентов семьдесят-восемьдесят - это норма, и недостающая часть не пропадает, её доотладка на опытной эксплуатации заложена в план заранее. Модель нужна для костяка: чтобы документооборот был сшит, чтобы аналитика проходила через все документы. Какие-то операции всплывут только на живой системе, и это нормально.
Отдельный случай - очень большие заводы. Мы такое проходили: завод в шестьдесят цехов, от заготовки до сборки, учёт в Excel, а у пары цехов свои собственные программы, которые они когда-то сами себе поставили. Ни один процесс от начала до конца там не знает никто, и это не фигура речи: у начальника в голове одна картинка, у подчинённых другая, у ИТ третья. Модель на таком заводе всё равно нужна, без неё вы даже не начнёте, но получите вы документ, в котором заранее сидят пропущенные процессы. Это свойство таких предприятий, а не брак работы - на заводе может просто не оказаться человека, способного осмыслить процесс целиком. Лечится делением внедрения на очереди: запустили кусок, люди на живой системе увидели, как оно работает на самом деле, следующая очередь моделируется по уточнённой картине.
Кто под кого подстраивается
Здесь развилка, о которой на Западе спорят давно, а у нас почти нет. Старый подход - blueprint: опиши подробно, как всё устроено сейчас, потом спроектируй, как будет, потом собери. Новый - fit-to-standard: покажи человеку стандартный процесс системы, а он скажет, где не подходит. SAP официально перешла на второй. Логика простая: типовой процесс в «1С:ERP» - это спрессованный опыт тысяч внедрений, и по умолчанию менять надо не его, а свою привычку.
У старого подхода есть беда глубже, чем абстрактность модели, и я её видел не раз. Когда вы подробно проектируете, «как будет», вместе с картинкой будущей системы вы получаете длинный список изменений, которые надо провести на местах: перестроить работу склада, переучить людей, поменять регламенты. Этот список - самая дорогая часть проекта, и её почти всегда забывают заложить в бюджет. Систему спроектировали, тома согласовали, а оргизменения так и не оплатили и не провели, некому и не на что. И тогда красивое «как будет» приезжает на завод, где всё ещё «как есть», и не запускается вообще.
На практике мы делаем гибрид: показываем заказчику работу на стандартном функционале, но на его данных и с оглядкой на то, чего хотят ключевые пользователи и владелец процесса. Тут одно жёсткое правило, и оно вам тоже пригодится: на демонстрации ничего не кодировать. Показываем типовое. Как только начнёшь под заказчика рисовать формы, чтобы «было понятнее», он тут же попросит дорисовать ещё, и ещё, - сроки растут, а проект стоит. Нет нужной подсистемы - рисуйте на доске блок-схему, включайте воображение, но не садитесь программировать посреди моделирования.
Когда всплывает разрыв, то есть процесс, которого в типовом решении нет, выходов три: поменять настройку, поменять свой процесс или писать доработку. Доработка - последняя в очереди. С нынешним потоком версий «1С» кодировать уникальное дорого вдвойне: каждое обновление будете чинить руками. Поэтому на любой разрыв идите с открытыми глазами - сколько стоит сама доработка и сколько потом стоит владеть ею годами. И решать это надо по ходу этапа, согласуя с владельцами процессов, а не в последнюю неделю моделирования, когда вам вываливают список из полусотни доработок разом.
Половину работы делает ваша команда
Функциональную модель нельзя сделать без заказчика, её делают вместе с ним, и добрую половину работы делает он. Кого включать в команду и сколько это стоит времени, я разбирал в статье про команду заказчика; здесь важно, что пик их занятости приходится ровно на этот этап.
Интервью на моделировании - разбор на рабочем месте: открой систему, покажи, что делаешь, на основании чего, а что делаешь, когда всё пошло не так. Хорошее интервью - это спор. Если консультант за сорок пять минут вежливо покивал и ушёл, интервью провалено.
И есть решения, которые за вас не примет никто. Перенос данных: тащим весь справочник как есть, тащим только то, что на остатках, или заводим заново. Дубли в своей номенклатуре знаете только вы, подрядчик их не опознает. Какие доработки правда нужны, а какие - привычка к старому экрану. Решаете вы.
Сколько это стоит в деньгах, я показывал в статье про стоимость внедрения: внутренние консультанты заказчика сами переписали требования к учёту затрат, и бюджет блока упал с двадцати миллионов до трёх. Мы тогда не расслабились и скидку не давали - просто хорошее требование оказалось дешевле плохого почти в семь раз. Считать цену требований мы умеем. Понять, что процесс можно не копировать, может только тот, кто внутри этого процесса живёт.
Сколько это длится и почему нельзя ускорить
Честная функциональная модель - от трёх месяцев на простом проекте до полугода на сложном. Не недели. Внутри этап делится примерно поровну на пять кусков: интервью, обработка протоколов, моделирование, демонстрация, написание и сдача документа. Хотите прикинуть срок сами - поделите этап на эти пять.
Отсюда понятно, чего стоит обещание «сделаем функциональную модель за неделю». Это обещание сжать полгода в неделю, то есть провал. За неделю можно нарисовать ровно тот самый каталог: все варианты плюс справка из системы, красиво и бесполезно. Если вам такую модель уже отдали и вы не уверены в качестве, покажите её на второе мнение - нам или любому опытному интегратору. Диагноз ставится за день.
Можно ли вообще без функциональной модели? Можно, это называется Agile, и я против него ничего не имею: он даёт быстрый результат, мы и сами так работаем, когда заказчик готов на почасовку. Но работает он при двух условиях - вы с подрядчиком доверяете друг другу и сидите на почасовке, где вы рискуете одним месяцем. На длинном проекте с фиксированной ценой всё иначе. Между тем, как вы спроектировали, и тем, как запустили, у вас пройдёт реорганизация, появятся новые направления, поменяются люди. И функциональная модель - единственное, что защищает обе стороны, когда мир вокруг проекта поменялся. Отказаться от неё значит взять эти риски на себя. Такое решают не на уровне руководителя проекта, а на уровне директора.
Как её принимать
Не читать вслух до запятой всей комиссией. У нас это называют «чтениями вслух» - по одному проекту, где три дорогих человека сидели и правили предлоги хором. Театр для комиссий, которым важна бумажка. Но и не подписывать не глядя, лишь бы отвязались.
Принимать надо так, и у нас этот порядок зашит в методологию приёмки: ключевые пользователи смотрят, как их процесс идёт в живой системе на демонстрации, и говорят, что верно, а что нет. Не пересказывают по памяти, а смотрят работающую систему и ловят несоответствия. Демонстрацию стоит писать на видео: кто болел или был в отпуске - пересмотрит, не придётся показывать по десять раз.
И про отношение к подписи. В статье про фикс-прайс я говорил, что согласованная модель задаёт границу цены: новая хотелка сверх границы - это платное допсоглашение. Так и есть. Но подпись под моделью - не капкан и не повод сказать «вы согласовали, теперь живите». Свои же ошибки в модели надо искать до последнего, и чем раньше, тем лучше: ранняя правка дёшева, поздняя разорительна. Граница защищает от новых хотелок и держит цену честной, а не выдаёт подрядчику индульгенцию не исправлять то, что он сам напутал. В игру «обсуждали, но не согласовали» против заказчика я не играю.
Где выигрывается «работает ли завод в системе»
Проект успешен, если предприятие в итоге работает в системе. Работать оно будет ровно в той системе, которую спроектировали на этом этапе. Функциональная модель - чертёж вашего будущего рабочего дня, и жить в ней будет не подрядчик, а вы. Поэтому «обследование», которое так хочется перетерпеть как формальность, - единственный момент, когда вы держите свою будущую работу в руках и ещё можете её изменить. Дальше будет только дороже.
И последнее, практическое. Этот этап не обязан жить внутри большого контракта: обследование с моделированием у нас - отдельный первый договор. Модель и смета остаются вам, чем бы ни кончились переговоры о внедрении.