Эффективное моделирование. Работа с видео демонстрации

Моделирование – это технология выявления функциональных требований заказчика при внедрении 1С:ERP. В типовую систему настраивают в соответствии с бизнесом заказчика и вводят в нее модельные примеры для всех операций компании. Для примера берется продукция, материалы, клиенты, поставщики и подразделения компании, чтобы сотрудникам заказчика было проще понять, как работает система. После подготовки примера проводится демонстрация работы системы для сотрудников. В ходе демонстрации мы должны решить, возможно ли на этом участке использовать типовую систему или требуется ее доработка. Если необходима доработка – готовим описание функционального требования. В итоге к концу этапа моделирования сотрудники заказчика ориентируются в системе и готовы отвечать за обоснованность предложенных доработок, а мы знакомимся с деталями работы компании на каждом участке и получаем реальную картину потребностей пользователей.
Обычно в качестве результата этапа моделирования мы передаем заказчику базу данных с модельными примерами и список функциональных требований. Но на одном из проектов заказчик предложил более интересный формат работы. Руководитель проекта со стороны заказчика попросил нас записывать демонстрацию – все, что происходит на экране, а также обсуждение системы с пользователями. Эти видео ИТ-отдел заказчика размещал в интернете, с доступом для сотрудников компании. Руководство требовало от сотрудников, участвующих в рабочей группе, просматривать эти видео, и, пользуясь ими, как пособиями, самостоятельно воспроизводить модельные примеры в отдельной тестовой базе.
После накопления некоторого опыта в работе с видео, заказчик попросил нас предоставлять им «тайминг» записи – в какой момент какой вопрос обсуждался. А позднее запись легла в основу приемки работ по моделированию. Мы договорились указывать, в какой момент записи проводится демонстрация по каждой операции, включенной в выполняемую консультантом заявку. Таким образом, если кто-то из сотрудников заявлял, что какую-то операцию не смоделировали или демонстрация проведена недостаточно подробно, всегда можно было сослаться на конкретный фрагмент видео. А затем уже предметно обсудить – достаточно ли качественно выполнено моделирование или просто выяснить, какой момент был труден для понимания и вызвал вопросы пользователя. Ценность видео мы оценили даже внутри нашей проектной команды, когда у одного консультанта появилась возможность просмотреть видео, подготовленное другим консультантом, и таким образом быть в курсе задач, которые обсуждались на другом участке работы. Вместо того, чтобы пересказывать разговор с пользователями, можно просто дать ссылку на момент обсуждения в видео. Кроме того, очень важно, что записи демонстраций остаются в качестве документа. Иногда на поздних стадиях проекта, приходится вспоминать, почему задачи на доработку были сформулированы именно таким образом и как проходило их обсуждение.

Тактика внедрения 8. Универсальные решения

При внедрении 1С:ERP приходится делать множество программных доработок, большинство из которых носит частный характер. Они нужны конкретному заказчику или даже пользователю, на конкретном участке системы. Тем не менее, нередко вместо множества частных мелких доработок можно создать одно универсальное решение. И если такая возможность предоставляется, надо обязательно ей воспользоваться.

Вот несколько примеров таких ситуаций, возникших при выполнении моих проектов:
Заполнение реквизитов. На этапе опытной эксплуатации заказчик поставил задачу реализовать контроль заполнения некоторых реквизитов в документе «Заказ клиента». Вместо того, чтобы добавить эти проверки в модуль этого документа, я после согласования с клиентом поручил программисту разработать функцию, которая проверяла бы заполнение любого реквизита в любом объекте. Кроме того, функция должна была проверять соответствие значения, указанного пользователем, заданному списку, а также возможность выполнить произвольную проверку данных объекта при помощи запроса. То есть, мы решили задачу выполнения любой сколь угодно сложной проверки любого реквизита в любом объекте системы.
Зачем я это сделал? Я понимал, что заказчик начинает выстраивать в системе регламент работы сотрудников. Он устанавливает для них какие-то ограничения и хочет автоматически проверять корректность их действий в системе. Следовательно, скоро понадобятся проверки и ограничения в других справочниках и документах, и на других участках. Дальнейший ход опытной эксплуатации показал, что я прав – заказчик начал вводить новые проверки. При этом он уже не обращался к нам, а самостоятельно пользовался созданной нами функцией. Это сократило для нас количество мелких дешевых доработок и позволило не отвлекаться от решения более важных и дорогих задач.
Права на изменения статуса. При запуске подсистемы управления денежными средствами заказчик попросил ограничить права сотрудников на изменение статуса заявки на расход денежных средств. Следуя логике, описанной выше, я принял во внимание, что в 1С:ERP во многих важных документах есть статус, и что задачи по ограничению прав на изменение статуса других документов вскоре обязательно появятся. Поэтому я поручил разработчику создать небольшое дополнение к системе прав доступа – в карточке пользователя добавить возможность указать любой объект со статусом, и статусы, при которых пользователь может изменять объект. Действительно, через некоторое время возникла потребность ограничить права доступа для заказов, клиента, складских ордеров и других документов. При этом никаких доработок делать уже не было нужно, работа свелась к настройке карточек пользователей, которую выполнил сам заказчик.
Загрузка данных от разных контрагентов. При автоматизации компании, занимающейся интернет-торговлей, возникла задача загружать в систему данные от разных служб доставки. На основании этих данных нужно было формировать складские документы, документы реализации и возвратов, а также обновлять данные о состоянии заказов. Кроме того, требовалось сверять сведения об оплате товаров, переданные службами доставки с данными из банка. Компания работала с несколькими службами доставки, и все они предоставляли данные в разном формате. Поэтому задача была выполнена следующим образом: сначала мы разработали универсальные объекты для хранения всех данных, передаваемых перевозчиками. Данные перевозчиков сначала загружались в это единое хранилище отдельными обработками. А документы 1С:ERP формировались уже с использованием хранилища.
Почему был использовано такое решение? Формирование учетных документов 1С:ERP – сложная и дорогая задача. Мы решили ее один раз, разработав модуль, который использовал для этого данные универсального хранилища. А загрузка данных из службы доставки – задача простая. Службы доставки могут измениться, или они могут поменять формат своих файлов. С выбранным нами решением в этом случае нужно только написать простой загрузчик новых данных в уже известный формат хранилища. С такой задачей легко справится служба поддержки компании, без нашей помощи. Алгоритм формирования документов 1С:ERP при этом менять не нужно – он использует данные хранилища, которые не менялись.

При постановке проектных задач нужно всегда стараться применить этот подход, пытаться обобщить задачи и решить их наиболее универсальным способом. Во-первых, при таком подходе вместо множества мелких задач мы делаем одну большую. Это упрощает управление и снижает риски кодирования, ведь каждая отдельная задача несет отдельный риск создания ошибок. Проконтролировать же качество в одной крупной задаче проще, чем во множестве мелких. Во-вторых, уменьшается количество постановок задач и их приемок. Эта условно-платная часть работы. Она необходима, но клиенту сложно объяснить, почему он должен за это платить, поэтому чем такой деятельности меньше, тем лучше. В третьих, универсальные решения можно применить на других проектах для других клиентов, сэкономив время и средства для решения более важных задач.

Тактика внедрения 7. Продающий дизайн

Одна из самых больших проблем программной разработки на заказ – отсутствие наглядного результата. Заказчик получает работающую программу, иногда очень дорогую, сложную, и эффективную. Но все это не видно ему глазами. Интерфейс программы совершенно не соответствует ни сложности и важности задач, которые она решает, ни уровню использованных программных решений. То, что может увидеть заказчик своими глазами никак не соответствует вложенным в разработку труду, таланту и опыту. В качестве примера можно привести внешний интерфейс известной системы по поиску данных в интернете, имеющей астрономическую стоимость: www.google.com.

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

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

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

В каждом отдельном случае можно придумать какой-то свой способ отразить программную доработку в интерфейсе системы. Дизайн программы не должен скрывать вашу работу, он должен помогать вам «продавать» ее заказчику при сдаче-приемке или запуске системы.

Как происходит проект внедрения 1С:ERP

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

Переговоры

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

Предпроектное обследование

До начала основных работ необходимо выполнить предпроектное обследование компании. Цель обследования – быстро выяснить ключевые сведения о компании, необходимые для планирования дальнейших работ по проекту. К ним относятся: подразделения, в которых будет использоваться система, сотрудники, которые будут в ней работать, список технологических и учетных операций, которые будут планировать или отражаться в системе. Также в ходе предпроектного обследования фиксируются проблемы, сложные задачи, уникальные особенности компании, которые могут повлиять на дальнейший ход проекта. Предпроектное обследование проводит руководитель проекта или наиболее опытный консультант нашей команды. Оно может занять от 5 до 10 дней, в зависимости от размеров компании и сложности ее бизнеса. По итогам обследования заказчику предоставляется отчет, в котором зафиксирована вся важная для проекта информация, а также уточняются объем и стоимость последующих работ.

Моделирование

Во время моделирования мы «пытаемся» работать в ERP-системе от лица заказчика, используя данные о его складах, товарах, клиентах, поставщиках, персонале и оборудовании. Мы встречаемся с руководителями подразделений и наиболее опытными сотрудниками заказчика, выясняем у них, как они работают, и пытаемся выполнить эту работу в ERP. Для этого мы с сотрудниками заказчика составляем модельные примеры – последовательности действий в системе и небольшую выборку реальных данных, которые нужно ввести в систему. После этого, мы отражаем в системе моделируемый участок работы и проводим для сотрудников заказчика демонстрацию. Мы показываем, как работает ERP с их товарами, клиентами, складами и пр. В случае, если работа системы не подходит для заказчика, мы записываем задачу по доработке системы – требование. Цель моделирования – составить полый список всех доработок системы, которые нужно будет выполнить, чтобы компания заказчика могла в ней работать. Моделирование выполняют консультанты, оно продолжается от 3 до 6 недель.

Доработка

В ходе доработки системы наши программисты дописывают типовую ERP, подгоняя ее под требования заказчика, зафиксированные во время моделирования. При необходимости консультант уточняет задачу у заказчика и дает соответствующие указания программисту. После выполнения доработки, наш консультант и заказчик проводят ее сдачу-приемку, используя контрольные примеры. После того, как все доработки проверены на контрольных примерах и приняты заказчиком, система готова к запуску. Доработки выполняют разработчики в паре с консультантами. Их работу координирует руководитель проекта. В зависимости от сложности проекта и требований заказчика доработка может занять от 2 до 4 месяцев.

Подготовка к тестовой эксплуатации

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

Тестовая эксплуатация

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

Послепроектное сопровождение 

После завершения тестовой эксплуатации компания заказчика полностью переходит на работу в ERP-системе, а проект внедрения можно считать завершенным. Тем не менее, в первые 2-3 месяца использования внедренной ERP-системы от пользователей может поступать значительное количество требований на доработку, могу понадобиться дополнительные консультации или обучение. Поэтому в течение 2-3 месяцев после запуска системы мы осуществляем сопровождение заказчика, продолжая выполнять доработки и консультировать пользователей. Сопровождение прекращается, когда со всеми обращениями пользователей может справится собственная IT-служба компании.