Как мы делаем проекты

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

Во-первых, наши основные компетенции — конфигурации (*) ERP, УТ11, и КА2, — мы ориентируемся именно на эти решения.

(*) здесь и далее — рассматриваем решения только на платформе 1С

Наиболее частые вопросы, которые стоят перед заказчиками:

Однако, между выбором решения и разработкой есть еще один этап — Моделирование. Именно этап этап позволит выявить необходимые доработки и дать первые оценки трудоемкости проекта

Выбор типового решения

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

Мы работаем с решениями ERP, УТ11, и КА2, которые являются одним семейством программных продуктов с разной функциональностью (за счет ограничений в КА2 и УТ11). Фирма 1С ведет разработку одного решения — ERP, а затем, при выпуске релиза, из ERP вырезают определенные подсистемы и получают продукты КА2 и УТ11.

Если говорить про линейку ERP/УТ11/КА2, то тут стоит отметить следующее.

  • ERP — полнофункциональный продукт из данной линейки — нет ограничений
  • КА2:
    • нет производства (большей части), учета ремонтов
    • нет МСФО
  • УТ11:
    • нет подсистем заработной платы и кадрового учета
    • нет бухгалтерского учета и налогового учета
    • нет производства, учета ремонтов
    • нет бюджетирования и МСФО

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

Магазинам и розничным компаниям рекомендован программный продукт 1С:Розница — универсальное решение для управления розничной торговлей

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

В случае, если заказчик настроен выбрать продукт линейки ERP/УТ11/КА2 — мы помогаем определиться с выбором конкретного решения. Следует также помнить, что фирмой 1С предусмотрена миграция с младших на старшие версии данного продукта (с УТ11 на КА2 или с КА2 на ERP).

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

Чтобы начать разработку, необходимо понять в деталях, как будет построена работа данной конкретной организации в данной конкретной программе. Этот подход получил название в нашей среде как «Моделирование», а работы, связанные с моделированием, являются важнейшим этапом любого проекта. Моделирование отвечает на два основных вопроса:

  • как организация будет отражать конкретные хозяйственные операции;
  • какого функционала в программе не хватает.

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

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

То чего не хватает — выливается в техническое задание (функциональные требования) и контрольный пример

Этап занимает 4-6 недель, но это очень сильно зависит как от масштаба проекта, так и от глубины проработки бизнес-процессов

Доработка системы

При доработке системы мы придерживаемся следующих принципов:

  • Система всегда должна оставаться обновляемой. Этому принципу следует придерживаться всегда, так как жизнь не стоит на месте. За 1-2 года могут появиться кардинальные изменения в законодательстве (онлайн кассы, маркировка единиц товаров, ставка НДС — последние примеры), которые потребуют серьезнейшей переработки системы и миграции данных со старой системы на новую. Обновление может пройти спокойно и практически бесплатно в случае обновляемой конфигурации, а в противном случае — вылиться в масштабный проект с серьезной разработкой, с миграцией данных, и с возможными простоями при внедрении. Все это вещи очевидные, но стоило о них напомнить.
  • Использовать типовой функционал. Даже если при первом знакомстве он кажется не удобен заказчику. Тем не менее, доработка возможна и в этом случае, но после всестороннего изучения вопроса, оценки плюсов и минусов с учетом дальнейшей эксплуатации системы и ее обновления. Типовой функционал более надежен, лучше оттестирован, более универсален.
    В качестве примера, приведу случай, когда доработка написана без учета характеристик номенклатуры (или серий) — так как организация не вела учет по характеристикам (сериям). А затем, организация решила вести учет по характеристикам. С большой степенью достоверности, в этом случае доработка перестанет работать.
  • Использовать возможности технологии расширения конфигурации. Это оправдано практически на всех проектах (но есть и исключения). Суть заключается в том, что конфигурация остается типовой, а доработки вынесены в расширения, которые представляют собой отдельные конфигурации в рамках общего решения (образно выражаясь, как бы пристройки к основному зданию). После обновления конфигурации возможны проблемы несовместимости, но они на порядок легче решаются, чем в случае доработки основной конфигурации решения.
  • При разработке придерживаться системы стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8. Это влияет на дальнейшую поддержку и развитие разработки. За годы работы сообщество разработчиков 1С сформировало эти стандарты и мы их используем. Детально не описываю, поскольку это технические подробности.
  • Приемка на контрольном примере. Очень полезный подход и очень хорошо описан моим коллегой, Александром Дзябченко. Суть заключается в том, что на этапе моделирования разрабатывается контрольный пример — цепочка документов или данные формы, что должна посчитать или сделать система после выполнения запланированных и описанных действий, причем с конкретными значениями. Очень полезный подход, так как снимает неопределенность на входе в систему и выходе из нее, очень полезен при разработке и тестировании.
  • Документация проекта. Документация, ее формат и глубина зависит от самого проекта и требований заказчика. На крупных проектах — все более менее стандартно: функциональные требования или эскизный проект. На средних проектах, как мне кажется, не стоит делать много документации до выполнения разработки. Скорее, ее стоит делать после разработки — непосредственно перед сдачей работы, со скриншотами на тестовых примерах. В небольших проектах она и вовсе не нужна, но может быть полезна пользовательская документация в виде набора скриншотов с комментариями.

Внедрение системы

Внедрение во всех проектах очень различается и зависит от характера проекта, отрасли, уровня подготовки пользователей.

Внедрение можно условно разделить на следующие подэтапы:

  • миграцию данных — перенос данных со старой системы на новую;
  • обучение пользователей;
  • запуск и начало работы.

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

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

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

Также полезно дать пользователям самостоятельно протестировать-поработать в тестовой базе. Обычно за пару дней до запуска новой системы. Объем и основательность подхода к обучению сильно варьируется в разных проектах.

Запуск и начало работы. Предполагается, что подготовка была проведена как положено, обработки миграции уже были протестированы несколько раз и все очевидные ошибки отловлены.

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

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

После некоторого перерыва, возможен этап консультирования и поддержки при процедурах «Закрытии месяца», но тут тема большая и опишу ее как-нибудь отдельно

Вам также может понравиться

About the Author: Павел Пчелинцев