Это был первый проект на базе данной системы. ERP еще только становилась. Выход коммерческого первого релиза состоялся в конце 2013 года. Так что каких то функций, которые были во флагмане программных продуктов существовавших на тот момент на рынке систем автоматизации (а им была система 1С:Управление производственным предприятием) не было вообще, какие-то функции работали совсем не так.
Предприятие, на котором производилось внедрение – компания «Гельтек-Медика». Компания создана на базе лаборатории НИИ медицинских полимеров. Направления ее деятельности - это разработка и производство медицинских ультразвуковых и электродных гелей и кремов, гелей и лосьонов для аппаратной и лазерной косметологии для домашнего ухода, медицинский изделий для ухода за веками.
Компания расположена в городе Москва. Имеет удаленное производство в г. Дедовск.
На момент внедрения на предприятии была внедрена система 1С:УПП. Хорошо она работала для целей управления продажами, управления закупками, учета затрат, ведения кадрового учета и расчета зарплаты, ведения регламентированного учета.
Производственный учет, диспетчирование и управление производством – это предприятию не хватало. Также не был реализован управленческий учет. Нельзя было оперативно, в одной системе, оперируя одной первичной информацией с регламентированным учетом, анализировать продажи, затраты в ином разрезе, интересном для бизнеса.
Дорабатывать старую систему не стали. Решили перейти на 1С:ERP, т.к. система предлагала удобные и более широкие возможности для управления и анализа деятельности предприятия, интересные связки с иными решениями линейки 1С, которые позволяют значительно расширять возможности информационной системы.
Давайте рассмотрим краткую схему бизнес – процессов у заказчика:
- Поступают заказы клиентов; формируется портфель заказов, с конкретными объемами и сроками поставки;
- Далее начальник отдела продаж, анализирует свободные остатки продукции и формирует на следующий месяц заявку в производство по тем позициям, которые надо выпустить;
- Диспетчер производства, получив заявку анализирует наличие сырья, формирует этапы производства. В соответствии со сроками отгрузки, с пожеланиями отдела продаж, с обеспеченностью сырьем определяет порядок выполнения заказов/этапов.
- Работники предприятия в своем рабочем месте видят, какие этапы они должны выполнить, в какие сроки. Т.к. продукция предприятия многоэтапная, то к выполнению конкретные операторы видят только те этапы, которые обеспечены сырьем, соответственно которые они могут выполнить (т.к. только после завершения предыдущего этапа).
- При выполнении работник указывает необходимые данные: какие материалы были потрачены, что было выпущено, какие операции были выполнены.
- Диспетчер постоянно мониторит процесс производства, контролирует выполнение этапов. После выпуска готовой продукции формирует отгрузку на склад готовой продукции.
По мере выполнения производством заказов менеджеры продаж производят отгрузку.
Сейчас мы рассмотрим схему , реализованную на предприятии заказчика на примере их бизнес-процессов.
- Фиксация потребности клиента
Создание месячного плана производства на основании статистики продаж за предыдущий период, спроса за предыдущий период, собранных заказов клиентов к обеспечению, складских остатков;
Планирование производства: формирование заказов на производство, формирование этапов производства;
- Управление производством:
* подготовка производственного процесса по этапам (обеспечение заказов материалами, передача к выполнению готовых этапов);
* отражение выполнения, указание информации о выпущенной продукции, расходе материалов
* проверка и контроль выполнения этапов, формирование передачи готовой продукции на склад;
Завершение процедуры обработки заказа клиента: контроль готовности заказа клиента к отгрузке, отпуск продукции Заказчику
При поступлении заказа менеджер фиксирует потребность с использованием типового документа «Заказ клиента». Первоначально заказ формируется в статусе «Ожидание согласования».
В заказе указывается ожидаемая дата поставки. В зависимости от требования клиента – весь заказ может быть поставлен к одной дате (тогда указывается одна дата отгрузки), либо в зависимости от потребности заказчика – можно дату предполагаемой поставки указать в каждой строке. Для этого флаг «Отгружать одной датой» не устанавливается, появляется отдельная колонка для указания предполагаемой даты отгрузки, где менеджер указывает соответствующие даты.
Правила оплаты. У заказчика используются типовые соглашения. По ним определяется график оплаты, например, 100% аванс до обеспечения (оплата заказа вообще до его выполнения), какой-то % после отгрузки и т.д. В конкретном заказе менеджер в зависимости от согласования с заказчиком и общим регламентом компании может поменять график. Система автоматически высчитает в зависимости от сроков ожидаемой отгрузки срок предполагаемой оплаты.
Если оплата должна быть до всех каких-либо действий, то менеджер выписывает счет, отправляет заказчику.
По заказам производится анализ возможности отгрузки запасов. Для этого штатным инструментом определяется, есть ли позиции на складе или надо их обеспечивать (по данным оперативных остатков системы это определяем сама).
Далее: в заказе определилось, что одну позицию можно отгрузить, а другая позиция еще не произведена. Менеджер созванивается с клиентом. Если клиент согласен, то отгрузка делится на несколько траншей – сначала грузится одна позиция, потом по мере готовности и возможности отгрузить – вторая.
Если Заказчик выбирает вариант отгрузки сразу целиком, а чтобы позиция, которая уже есть была зарезервирована на складе, тогда при определении обеспечения нужно выбрать не «Отгрузить», а «Резервировать». В этом случае имеющаяся позиция будет оставаться на складе в ожидании комплектования всего заказа.
Другие две позиции – это позиции к обеспечению. Их надо произвести (для производимых позиций), либо закупить.
Другой заказ. Менеджер обработал обеспечение – получил информацию, что может отгрузить заказ сразу (все позиции есть на складе). У заказчика ведется учет по сериям. Также настройками системы определено, что менеджер определяет какую серию надо отгрузить. Серия номенклатуры продукции определяется номером и сроком годности. Причем, у продукции и полуфабрикатов серия одна. Это очень удобно. Ведь серия в химической промышленности определяем партию, на именно эту серию навешиваются параметры качества, которые должны быть соблюдены. Эта фишка была использована в этом проекте.
Поэтому, при оформлении заказа менеджеру надо указать серию. Поскольку позиций номенклатуры в заказе много, то для облегчения работы менеджеров сделана обработка, которая подбирает автоматически серии. Также поскольку был сделан блок учета качества и в серии отражалось – пройден ли контроль или нет, то проставление серии производится только по годным сериям.
Если по заказу все позиции можно отгрузить, то у нее меняется статус на «К выполнению». При этом проверяется – выполнены или нет условия по оплатам (если требуется аванс до отгрузки).
Перейдем к планированию производства.
Ежемесячно составляется план производства на месяц. Числа 20 – 25 производится планирование.
При составлении учитываются следующие аспекты:
1) Статистики предыдущих продаж
2) Прогноза рыночного спроса
3) Складских остатков
4) Необеспеченные Заказы клиентов
5) Минимального объема выпуска (меньше 600 кг в производство запускать не будут)
Поскольку заказчик не стал доверять автоматическому формированию плана и поскольку есть ряд субъективных показателей, которые невозможно учесть в формуле, было принято решение полу-ручного формирования плана. А именно.
Для определения и анализа предполагаемых объемов пользователи используют следующие отчеты:
- Валовая прибыль по продукции;
- Товары на складах;
- Необеспеченные заказы.
Для упрощения работы заполняется по плану производства по данным плана производства за предыдущий месяц, используется простая формула; номенклатура в этом случае в зависимости от ситуации либо из формулы выбирается, либо номенклатуру заполняют при копировании документа плана предыдущего месяца, а объем заполняют автоматически по формуле; также номенклатуру можно по группе брать, но в этом случае могут быть строки, которые не будут иметь количества (не было в планах производства предыдущего месяца).
Планирование производится по производственным площадкам. Поэтому добавлена аналитика вида плана – подразделения.
По кнопке заполнение (заполнение по формуле, что обсуждали выше) происходит заполнение количества.
Пользователь вносит коррективы при необходимости. Производится согласование плана. После согласования статус документа меняется на «Согласован».
Для удобства анализа был сделан отчет «План производства (мин-макс)», который позволяет анализировать (рекомендовать) какое количество продукции целесообразно произвести.
По этому отчету отображается информация по свободным остаткам продукции, несогласованным заказам, средний расход (средняя отгрузка в месяц по позиционно), минимальное и максимальное товарное движение. Статистика вводится по позиционно в Товарные ограничения. И три графы последние отображают: если заказывать по минимуму, если заказывать по максимуму, а если еще и несогласованные заказы (которые не факт что будут согласованы) учесть. Индикатором подсвечиваются позиции, на которые стоит обратить внимание – т.е. вроде бы можно и не заказывать еще, но возможно нужно. Здесь менеджер принимает решение. А какое его будет решение – поставить в план по минимуму или максимуму или нечто среднее – это уже конкретное управленческое решение. И в план производства эти данные вносятся вручную.
Немного о товарных ограничениях. Данный механизм используется и для закупок, и для производства.
Для каждой номенклатуры и склада указывается порядок обеспечения, т.е. по статистике Мин-макс (пользователи сами определяют этот минимальный/максимальный объем, который будут принимать в расчеты), либо обеспечение под заказ (есть заказы – потребности, есть необходимость обеспечения), можно по статистике (расчет потребления по статистики рассчитывается системой автоматически).
Для планирования производства принято решение, что будет использована минимальная/максимальная потребность для проведения анализа. А уже конкретное количество определяется менеджером.
Да, вы скажете, что какое-то странное планирование. Надо формировать план продаж, его утверждать и только потом план производства. Безусловно, методология системы именно такова. Однако, необходимо учитывать требования конкретного предприятия, его процессы, персональный состав. Именно это и может изменить/скорректировать/модифицировать общую концепцию. Да, мы пошли на то, чтобы минуя план продаж менеджеры сразу формировали план производства (заявку на производство). Планирование производится только на месяц (краткосрочное). Долгосрочного планирования не ведется – по долгосрочным планам оценивается аналогичный период предыдущего года и учитывается тренд повышения или снижения активности. Тем более, в текущее время долгосрочное планирование теряет свою прелесть.
По созданному и согласованному плану производится запуск производственного процесса. В системе используется заказ на производство. Формирование происходит типовым механизмом: в журнале заказов, формирование по плану.
В силу специфики в один заказ объединяются продукции, на производство которых идет один полуфабрикат.
Типовой механизм работает следующим образом:
Из списка заказов на производства, нажимаем кнопку «Создать»;
Появляется меню: по плану или по потребности
Далее открывается форма, где указываются доп. параметры, которые участвуют в формировании заказа:
* поскольку планирование от плана, надо указать сценарий
* период, на который составляется план;
* т.к. у нас доп. анализа при планировании используется (подразделение диспетчер), то его также надо указать.
Существенный момент – это реквизит «Режим расчета потребностей». Он предусматривает несколько вариантов:
1. Раздельно по периодам запуска, раздельно по периодам выпуска. Вообще режим расчета раздельно по периодам потребности разделены по периодам как и в исходных планах. Т.е. если исходная потребность на май и отдельно на июнь, то будет 2 строки – одна на период май, другая на период июнь.
2. Нарастающим итогом по периоду запуска, нарастающим итогом по периоду выпуска. В этом случае количество к заказу рассчитывается за весь период, начиная от заданной даты по текущий период планирования. В таком режиме можно учесть перевыполнение/недовыполнение планов по заказам.
Период запуска рассчитывается с учетом нормативной длительности производства, определяемой из ресурсных спецификаций продукции.
На предприятии заказчика используется методика Нарастающим итогом по периоду выпуска.
Далее система на основании запланированных данных предлагает к заказу позиции. Пользователь может изменить то количество, которое принимает в конкретный заказ (в нашем случае объем ограничивает и производство из одного полуфабриката). И по кнопке «Сформировать заказ» создается заказ на производство.
В созданном заказе можно дозаполнить реквизиты, которые не заполнились автоматически. Написать какие-то комментарии и т.д.
При проведении заказа система сигнализирует о необходимости дозаполнить реквизиты – например, введен реквизит «Код замочки» (это некий признак будущей партии, каждой партии смеси в чане присваивается свой код), склад получатель. Также производится контроль объема полуфабриката. Две продукции в соответствии со спецификациями производятся из одного полуфабриката, производимого по одной спецификации, то контролируется кратность – т.е. один заказ = одна емкость полуфабриката. Тут пользователь уменьшает требуемое количество. Предупреждение носит рекомендательный характер, при необходимости, производство полуфабриката может быть больше – в этом случае делается два замеса.
Склад автоматически проставляется при записи документа на основании склада, указанного для подразделения в настройках (типовой функционал).
Также диспетчер указывает желаемую дату выпуска (автоматически проставляется конец месяца, т.к. формирование производится от плана производства месячного) и дату предполагаемого запуска.
Заказы управляются с помощью присвоения статусов: формируется – только созданный заказ, к производству – то, что принято диспетчером к производству; закрыт – либо выполненный заказ, либо закрытый по каким-то другим причинам.
После формирование заказов диспетчер должен сформировать этапы производства. Рабочие не оперируют заказами, для операторов производства инструмент – это этапы производства, которые они должны выполнить.
Этапы формируются из формы заказа: «Структура заказа». Далее в окне структуры выбирается «Сформировать». Система запрашивает, что делать по требуемым полуфабрикатам или материалам – обеспечивать (т.е. передавать возникновение далее по цепочке, в этом случае должны использоваться схемы обеспечения), резервировать или не обеспечивать.
Сформировать этапы можно и в рабочем месте «Управление очередью заказов к производству». Особая пиктограмма справа (выделена цветом) определяет, что по данному заказу не сформированы этапы.
По схеме работы на предприятии формируются заказы за производство, по ним формируются этапы. Причем этапы могут формироваться заранее. И планирование выполнение осуществляется уже на уровне этапов.
Типовой механизм предусматривает еще вариант планирование на уровне заказов, но на данном предприятии не стали его использовать.
Конечно, этапы по заказу сформируются, если сформирована система спецификаций. ERP поддерживает создание дерева спецификаций. Поэтому отдельно можно делать спецификации на полуфабрикаты, отдельно на продукцию.
В спецификации указывается для производства количество выходной продукции, для которой формируется спецификация. На закладках материалы/работы – указывается сырье, полуфабрикаты или работы сторонние, которые потребляются в процессе производства продукции.
Добавлены свои реквизиты – «Нужна отметка» и «Необходим контроль» - для необходимости контроля веса по материалам и необходимости указания в этапе отметки, что контроль проведен. Без данной отметки этап не закрывается.
Важен реквизит «Способ получения». Здесь можно указать, что данная позиция должна обеспечиваться – т.е. по схеме обеспечения (либо перемещаться с другого склада, либо производиться, но в этом случае заказ будет формироваться по потребности), либо производиться на этапе – в этом случае не будет выделение полуфабриката, либо, что производится по отдельной спецификации. В этом случае будут отдельные этапы для производства полуфабриката. И в нашем примере (когда 2 продукции из одного полуфабриката делаются), полуфабрикату создается общий объем, а не задваивается.
Еще указывается статья калькуляции – это уже в блоке затрат проявляется для оценки структуры.
Графа «Применение материала» – определяет будут ли в этапах сразу указываться данные материалы или заполняться будут по требованию. Указание использования не всех материалов можно требовать от операторов производства, только те позиции, которые важны. Остальные материалы могут распределяться на выпуски (этапы) в конце месяца пропорционально базе распределения, которую можно определить для каждого расхода отдельно.
Также важно в спецификации указание выполняемых этапов. При внедрении не было введено пооперационного планирования и отслеживания - это достаточно трудоемко оказалось для клиента. Остановились на этапах. Этапы производства разбили так, как хотелось отслеживать. По этапам спецификации и будут формироваться этапы для производственников (операторов).
Колонка «Порядок» определяет последовательность. За счет нее можно этапы распараллелить, указать кто за кем следует.
В этапе указывается в каком подразделении производится выполнение. Своими силами или переработчиком, длительность.
Добавили свои реквизиты для контроля – требуется или нет контроль качества, нужно ли забирать образцы и т.д.
Вернемся к материалам – чтобы понимать, на каком этапе какой материал нужен – это указывается на закладке материалов/работ.
У спецификаций также есть механизм статусов: в подготовке, действует, закрыта. И можно установить основной. Если продукция может выпускаться всегда по – разному. Например, в нашем случае, полуфабрикат может выпускаться в разных баках разной емкости, поэтому спецификаций создано столько сколько емкостей и ни одну нельзя установить основной – поэтому для таких полуфабрикатов не задана ни одна основная спецификация, ее пользователь при подготовке заказа/этапа/или спецификации верхнего уровня должен указать.
Итак, по сформированным этапам диспетчер определяет – можно начинать производство или нет. В рабочем месте диспетчирование этапов этапы можно отфильтровать по подразделению диспетчеру, по заказу или коду замочки в нашем случае. Наш заказ разложился по всей цепочке, включая производство и полуфабриката (по технологии выпуск производится одномоментно – в чан положили необходимые компоненты, выдержали, перемешали и расфасовали во флаконы). Диспетчер видит – обеспечены у него этапы материалами или нет.
Далее он сам определяет какие этапы можно начинать. Для этого проверяет обеспеченность материалами – об этом сигнализирует пиктограмма.
Соответственно в этапе необходимо произвести обеспечение (аналогично, как мы рассматривали ранее для заказов клиентов).
Система сама определит что есть в цеховой кладовой (а проверяет она это в цеховой кладовой) или что этой позиции нет и нужно ее с центрального склада завести.
Также в этапе указывается бригада, которая будет выполнять этап. Т,к. не используется сделка не стали использовать закладку трудозатраты для простоты, добавили реквизит этап в документ и рабочий центр.
По необеспеченным материалам необходимо разместить заявку на склад. В журнале «Заказ на материалы в производство» создается заказ по потребностям. Удобное рабочее место, которое позволяет сформировать заказ. Указывается склад потребности, далее система автоматически анализирует – есть или нет потребности. Определяется по какой стратегии есть потребность и в какую дату. Далее система сама определяет для каких этапов какая потребность есть, если необходимое количество в цеховой кладовой или требуется переместить. Те, что требуется переместить указывается к заказу. Причем анализируются все этапы, которые созданы.
Далее формируется заказ. Информация с какого склада производить обеспечение – определяется в настройках обеспечения.
Однако такой путь ручной обработки достаточно долгий. Поэтому была создана групповая обработка этапов. Вызывается из рабочего места диспетчирования этапов. Перед ее запуском помечаются этапы, которые необходимо обработать. В обработке можно указать (заполнить) бригаду, которая выполняет этапы, рабочий центр, произвести резервирование материалов, сформировать серии выходных изделий. Отдельно выполняется просто заполнение этапов. Также можно заполнить этапы и передать их к выполнению.
Далее технолог в заказе материалов в производство заполняет обеспечение (аналогично, как в заказе клиента). Система определяет сама, что можно отгрузить. Проставляет серии, которые можно отгрузить (это доработка). Серии проставляются по ФЕФО с учетом проверки качества сырья. И меняет статус к выполнению.
Склады сырья на предприятии не ордерные. Поэтому кладовщик пользуется рабочим местом «Внутренние документы (к оформлению)». Видит, какие материалы и каких серий нужно набрать и передать в производство, делает набор и оформляет документ передачи вводом на основании данного распоряжения (кнопка «Оформление по заказам») документа «Передача материалов в кладовую».
Технологу после получения надо опять найти этапы, которые требуют обеспечения и зарезервировать материал.
Как видим все этапы переданы к выполнению. Для операторов будет отображаться, какие уже можно (и нужно) начинать, какие система им не даст начать, т.к. будет ожидаться выполнение предшествующих.
Для производственников был сделан отдельный АРМ. Он был приспособлен к мобильным устройствам.
В обычном приложении это выглядит так, как представлено ниже.
Оператор выбирает этап, стартует (кнопка «Начать»). Для информирования отображается какой этап будет следующий.
По выполняемому этапу оператор указывает фактический расход материалов. На закладке параметры операций – указывается выполнены или нет определенные действия : нагрев воды, внесение консервантов и т.д. Конечно, эти параметры что надо контролировать идут из ресурсных спецификаций, оператору остается только выполнить действия и отметить – сделал он это или нет. Из ресурсных спецификаций на закладке «Инструкция» может быть указана подробная инструкция последовательности действий, к которой оператор может обратиться в случае сомнений в правильности им выполняемых действий.
Также на данном этапе необходима отметка контролера – т.е. приглашается сотрудник ОТК, который должен проверить правильность указания данных. Об этом свидетельствует цветовое напоминание, а также этап нельзя завершить без этих отметок (система не позволит).
Указывается контролер. И в расходе материалов, параметрах оборудования, где это требуется, он проставляет свою отметку.
Диспетчер в своем рабочем столе онлайн видит все отражение процесса. Какие этапы уже выполнены (завершены), какой следующий ожидается. Видны временные показатели, видно кто стартовал, кто завершил этап.
Поскольку в системе были реализованы механизмы контроля качества как входного, так и на этапах производства, то этапы, где требуется контроль качества, вводятся не только параметры оборудования, материалы, но и параметры качества.
Последовательность этапов в общем случае такова, что выпуск продукции или промежуточного полуфабриката может быть не на каждом этапе, а только на некоторых. Поэтому при построении цепочки производственной нужно уделить внимание тому, чтобы не включить много ненужных/плохо учитываемых полуфабрикатов. А создать выпуски только там, где это целесообразно.
Для готовой продукции организована сразу из рабочего места оператора печать ярлыков, которые сразу наклеиваются на транспортную упаковку.
Из АРМа автоматически при завершении последнего этапа, оформляется передача готовой продукции на склад. Это для данного конкретного клиента, т.к. специалист отвечающий за цеховую кладовую и специалист, отвечающий за склад ГП этого же производства, одно и тоже лицо. Эта передача на склад при производстве (оптовый склад).
На склад для отгрузки (это отдельный), технолог делает перемещение. Либо партиям в течение дня, либо в конце дня. Ориентируется на остатки склада при производстве. Передаются только серии, которые имеют проверенный статус качества.
Также сделан механизм Автоматическое диспетчирование этапов производства:
- резервирования необходимого сырья и материалов для созданных и необеспеченных этапов производства на основании текущей потребности;
- генерирования серий выходных изделий;
- при заполнении всех необходимых полей переводить этап в состояние «К выполнению».
Данная обработка автоматически по расписанию отбирает те этапы:
1.Которые необходимо стартовать не позже чем конец сегодняшнего дня (текущее время сервера 1С) + горизонт планирования по плановой дате начала производства этапа;
2. Которые находятся в состоянии «Сформирован» и не относятся к сторонним переработчикам;
3. В которых не всё необходимое сырье/материалы стоят в резерве;
Под которые можно зарезервировать, исходя из свободных остатков в цеховой кладовой
Этот механизм достаточно облегчил работу технологов.
Также создано регламентное задание, которое создает заказы на материалы по тем позициям материалов, которых нет в цеховых кладовых.
Для контроля обеспеченности сырьем создали отчет Контроль этапов по подразделениям.
Данный отчет служит для отображения необеспеченных и не переданных к выполнению этапов производства с указанием какого сырья или материала не хватает для передачи в производство.
Для контроля используются типовые отчеты:
- Исполнение плана производства
- Выпуск продукции
- Движение материалов и продукции – отдельно отображаются материалы, отдельно продукция/полуфабрикаты.
Отдельным отчетом (Заказы и запасы) анализируется – есть ли продукция к отгрузке, какие заказы требуют данную продукцию. И на основании этих данных, менеджер делает отгрузку по своим заказам.
На основании заказа формирует накладную, счет-фактуру.
Кладовщик склада в рабочем месте после выписки накладной видит распоряжение на отгрузку и создает ордер. В ордере также сделана доработка – сразу выделяются целые упаковочные места.
У ордера тоже есть несколько стадий выполнения – подготовлен, к отбору, проверка, ( и т.д.), к отгрузке, отгружен.
Отчет о состоянии заказа (типовой) показывает всю информацию, как по позициям - отгружены ли они, оформлены ли документы, так и по финансам – какова задолженность, просрочена ли она.
Внедрение от начала подготовки (обследования и построения модели учета) до завершения опытной эксплуатации с учетом перехода регламентированного учета – 1 год 4 месяца.
Проект велся методом постепенного перехода с 1С:УПП на ERP, т.е. по блокам с поддержкой данных в исторической учетной системе.
Данный проект велся удаленно: клиент в Москве, подрядчик – Нижний Новгород. Выезды были: на детальное обследование по блокам, но не по всем. По некоторым блокам выяснение и закрепление требований также производилось удаленно. Презентация и обсуждение моделей, настройки, приемка настроек, подготовка базы к эксплуатации (перенос данные), обучение – все производилось удаленно с использованием современных технологий коммуникаций. Опытная эксплуатация была выездная только на первом этапе, когда запускались первые блоки: Склады, Закупки и продажи. И при запуске блока производственного учета. Причем это были выезды не более 5 дней на каждый запуск. Вся остальная опытная эксплуатация велась удаленно: первые дни ежедневные скайп конференции, обсуждение проблем, вопросов. Чем более стабилизировалась система – скайп конференции переводили в режим еженедельных. Для фиксирования обращений пользователей использовали систему управления обращениям Итилиум компании ДеснолСофт. Для помощи в сложных вопросах пользователей – прямые подключения к их рабочих столам через AmyAdmin и другие приложения.
И еще хотелось бы остановиться, какие главные моменты нужно прорабатывать при внедрении:
Это проработка нормативно-справочной информации. Основные – это справочники группы Номенклатура: виды номенклатуры, Характеристики, Серии и т.д. Настройка схем обеспечения тоже снижает трудозатраты пользователей при формировании документов.
Для производственных предприятий – это оптимальное построение системы ресурсных спецификаций и выделение оптимальной цепочки этапов производства.
Согласование данных моментов снижает проблемы при запуске. Особенно это касается номенклатуры – задним числом изменение политики: без учета по сериям на учет по сериям - очень чревато для системы с уже заполненными данными.
На этом обсуждение примера внедрения подошло к концу. Готовы ответить на вопросы.
