Заказать звонок
Можно ли внедрять УПП на небольших фирмах с небольшими затратами? Это попытка рассказать об итерационной технологии внедрения на живом конкретном примере. Один раз в неделю Заказчик присылает свою базу и вопросы по ней, на один час автор связывается со IT-специалистом клиента по Skype и консультирует его. Прошло два месяца. Результаты перед вами.
«Скоро сказка сказывается, да не скоро дело делается» — так коротко можно резюмировать то, что удалось сделать за это время. И дело вовсе не в том, что не хватало большой группы внедренцев, которые, навалившись разом, всю работу бы да ка-ак сделали! Все намного прозаичнее: отпуска и болезни сотрудников, курсы повышения квалификации, прокладка локальной сети, апгрейд компьютеров…Текущая жизнь во время внедрения не останавливается. И подготовка проекта часто далека от идеала. Обычное внедрение чем-то напоминает «квест»: свои злодеи, неожиданные препятствия и подарки судьбы, переход на новый уровень только после прохождения уровня предыдущего.
Определив приоритетом текущей работы внедрение производственного учета, с начала июля 2012 сделано следующее:
· Подписаны приказы об обучении мастеров и конструкторов-технологов. Обучение затянуто из-за периода отпусков. Предполагалось, что с начала сентября мастера производственных участков все документы начнут оформлять в УПП. Но мастера, в основном, избегают обучения, ссылаясь на занятость. С конструкторами обучение идет легче. В процессе обучения ведется Лист учета. По нему сразу видно, кто думает, что процесс внедрения УПП может заглохнуть. На планерке генеральный директор огласил фамилии таких «мудрецов» и пообещал свое особое внимание к ним.
· Идет формирование контрольного примера по документообороту для одной продукции. Уже ясно, что нужны Заказы покупателей, Заказы на производство, Задания на производство, Отчеты производства за смену, Требования-накладные и Перемещения товаров.
· Идет формирование справочника Номенклатура. Сначала номенклатуру просто перегрузили из Бухгалтерии. Потом из вышестоящей организации прислали свой вариант видения группировок номенклатуры. После общения с конструкторами появился третий вариант подхода к формированию справочника. Все отстаивают свое мнение. А внедренцу остается только вспомнить, что ответило армянское радио на вопрос: «Можно ли изнасиловать женщину в центре Еревана? Нельзя, советами замучают.»
Часто продукцию, занимающую в собранном виде много места, отгружают заказчикам в виде пакетов деталей. В нашем случае отгрузка состоит из нескольких таких пакетов, которые, в свою очередь, тоже формируются из нескольких пакетов-полуфабрикатов. Поэтому напрашивается мысль использовать для продукции и полуфабриката предыдущего передела тип номенклатуры «набор-комплект» или «набор-пакет».
В карточке единицы измерения «тонны» для Закладной детали ЗД1 мы опять видим тонны. Что за «масло масляное»? Просто есть меры веса и объема, которые указываются в Настройках параметров учета -> Печать, единицы измерения и используются в ТТН (см. скриншоты Вес в параметрах учета и Тонны и литры). И распространенные ошибки в использовании разных единиц для номенклатуры состоят в том, что либо не указывают коэффициенты пересчета из одной единицы в другую, либо путают единицу веса, установленную в параметрах учета и единицу измерения для номенклатуры.
Теперь переходим на вкладку Спецификации (см. скриншот Спецификация на Закладную деталь). Так и есть, чувство не обмануло: из 0,67 кг арматуры получают 1 кг Закладной детали. Вывод: возможно в спецификацию должно входить что-то еще. Но найденный ранее вес 100 деталей говорит о том, что с весом все верно. Тогда ошибка в том, какую единицу измерения указали для спецификации: нужно указывать 1 шт, а не 1 кг. Случайность?
Но со справочником Номенклатура нужно что-то решать. Впрочем, кроме группировок есть и другие вопросы по этому справочнику.
Отличаются они тем, что если в документе «Реализация товаров и услуг» будет указана номенклатура с типом «набор-комплект», то списываться со склада будет не она сама, а ее комплектующие. Для номенклатуры с типом «набор-пакет» в документе «Реализация товаров и услуг» при подборе будет указана не сама номенклатура, а ее состав. Мы должны указать в документе «Реализация товаров и услуг» наименование конечной продукции, поэтому «набор-пакет» нам не подходит. Кроме того, «набор-пакет» в Заказы покупателей вообще входить не должен. Об этом говорит служебное сообщение: «Наборов-пакетов здесь быть не должно!».
Поэтому нам ближе «набор-комплект».
Но сначала мы обнаруживаем, что «набор-комплект» не может входить в другой «набор-комплект». При попытке записать его в комплектующие выдается служебное сообщение: «Комплектующая не может быть набором-комплектом!»
Оставляем «набором-комплектом» только конечную продукцию. Но теперь обнаруживаем, что становится сложно просмотреть и проверить ее состав. Обработка Конструктор спецификаций, который легко делает разузлование многопередельной продукции, комплектующие «не видит», и других методов просмотра нет. Во-вторых, при попытке создать Заказ покупателя на такую продукцию, документ пытается обращаться именно к цене комплектующих, так как начинает выдавать сообщения «В строке номер "1" табличной части "Состав набора": Не заполнено значение реквизита "Цена"! В строке номер "2"»… и так далее.
Вот и получается, что «при всем богатстве выбора другой альтернативы нет». И для продукции, и для полуфабрикатов устанавливаем тип номенклатуры «Товар». А обработкой Конструктор спецификаций проверяем состав Продукции №1, на основе производства которой и будет сделан контрольный пример.
«Характер нордический, стойкий. Беспощаден к врагам рейха.» — такова была характеристика на Штирлица.
У нашего клиента одно и то же изделие изготавливается из стали разных марок. Нужно ли использовать характеристики номенклатуры?
В 2002 году фирма «1С-Рарус» разрабатывала специализированное решение для мебельных предприятий. Тогда разработчики столкнулись с ситуацией, когда для одной модели дивана может использоваться до 1600 разных тканей. Создавать такое количество элементов номенклатуры потенциальные пользователи не соглашались: диван-то один. Выходом из сложной ситуации послужило создание и учет по дополнительным характеристикам номенклатуры. Теперь типовые конфигурации КА и УПП имеют эту возможность.
Но если характеристик две-три, а производственный процесс сложен, то можно по-прежнему создать разные элементы номенклатуры и не включать флаг «использовать характеристики номенклатуры». Тем более, что учет по характеристикам и расчет себестоимости по характеристикам настраивается в программе отдельно. К тому же для проверки правильности работы всех этих хитросплетений в каждом новом релизе программы нужен именно «нордический характер».
«Погубят тебя слишком большие возможности», — сказал доктор Айболит Бармалею, когда тот собрался его утопить, повесить и изжарить одновременно. Предоставленные в 8-ке большие возможности использовать для одной единицы номенклатуры разные единицы измерения часто приводит к проблемам и ошибкам пользователей. В нашем случае они (пользователи) их не миновали.
Вот полуфабрикат Закладная деталь ЗД1 (см.скриншот Закладная деталь). Не знаю, как у вас, но мое «шестое чувство» заставляет насторожиться при виде этих единиц измерения. Сколько весит эта деталь? Самое длинное число коэффициента пересчета в штуки указано для тонны.
Чтобы не переходить в тысячные доли лучше «укрупнить» вопрос: сколько весят 100 деталей? Чтобы не считать каждый раз заново, лучше ввести такую единицу измерения сначала в Классификатор единиц измерения подбором из ОКЕИ, а потом в справочник.
1*100/ 1492,537= 0,067 т
Вносим в справочник найденное значение. Для более мелких деталей можно вносить вес 1000 шт. и более.
Берем еще один полуфабрикат Бетон B15. Для него установлена одна единица измерения: «тонна». Смотрим спецификацию (см. скриншот Бетон). Заметите ли вы ошибку сами?
Теперь проверим, совпадает ли ход наших мыслей. На выходе спецификации указана 1 тонна полуфабриката «Бетон». Для его изготовления берутся материалы, масса которых при сложении даст общую массу бетона: (0,388 т + 0,835 т + 0,987 т + 0,002 т) = 2,212 т. и это еще без воды. Другими словами, меньше двух тонн бетон, выпущенный по этой спецификации, весить не может. Тогда спецификация может быть не на 1 т, а на 1 м3. Еще нужно уточнять, идет ли речь о весе влажного бетона или сухого. А если бетон отгружают покупателю, то единицей объема для ТТН нужно устанавливать не «л», а «м3».
Чтобы проверить, правильно ли составлена спецификация и пересчет в разные единицы измерения, лучше сразу сделать ОПЗС на выпуск 2-х единиц полуфабриката или продукции, и на вкладке Материалы, заполнив по спецификации, сверить данные с контрольными цифрами.
Не знаю, как вам, а мне стало немного страшно: если детально не проверить КАЖДУЮ спецификацию и единицы измерения к номенклатуре, то всегда найдутся «умники», которые спишут эти «косяки» на ошибки работы программы, и внедрение может на этом закончиться! «Титаник» может потонуть, не выйдя из гавани!
Создание любого сложного объекта начинается с модели. Кроме моделирования в конструкторе спецификаций нам еще нужно разработать и утвердить модель документооборота на контрольном примере. Иными словами, в базе нужно создать все документы для производства одной продукции: от заказа покупателя до отгрузки. Только после создания и утверждения всеми заинтересованными лицами такой модели можно говорить о том, что процесс внедрения УПП на данном производстве будет реальным. Правильнее это делать ДО покупки УПП, на этапе предпродажного обследования.
После некоторых метаний выбрали простую продукцию, производство которой происходит в 2 передела. Именно ее полуфабрикаты я придирчиво проверяла (см. выше). И хотя ошибки в спецификациях еще исправляются, тем не менее, мы снова и снова прогоняем эту продукцию через воображаемый заказ и производство. Схема документооборота тоже претерпевает свои изменения в связи с пожеланиями головной организации и пользователей на местах. Плюс на этом примере идет обучение пользователей.
Итак, все начинается с Заказа покупателя. На основании Заказа покупателя вводится Счет на оплату покупателю и Заказ на производство (см. скриншот Документооборот). Заказ на производство может разузловать продукцию до предыдущего передела (полуфабрикатов). А Заказ на производство, введенный на основании первого Заказа на производство, разузловывает полуфабрикаты уже до покупных материалов. Тогда можно делать Заказ поставщику. Конечно, в реальном варианте Заказы поставщикам будут делаться обработкой Помощник планирования, так как она позволит обрабатывать много Заказов на производство и делать Заказы поставщику для многих контрагентов.
В начале встречались трудности: у пользователей не заполнялся Заказ поставщику. Причина была проста: сначала создали документы ОПЗС, а потом пытались автоматически заполнить Заказ поставщику. Пришлось показывать отчет о движениях этих документов и объяснять, что в регистр «Потребности заказов на производство» документ Заказ на производство пишет Приход, а документ ОПЗС пишет Расход. Если потребности отсутствуют, то и Заказ поставщику заполняться не будет.
Неприятие вызвало то, что в Заказе поставщику не всегда происходило сворачивание строк с одинаковой номенклатурой. Пришлось объяснять, что в табличной части документа такое повторение обусловлено рядом причин, но в печатной форме к этому документу сворачивание по номенклатуре произойдет обязательно.
В общем, опасения постепенно идут на убыль: производство клиента действительно вписывается в схему стандартной конфигурации УПП. А учредитель требует с нового года перевести работу всех служб в единой базе на основе УПП.
Заседание рабочей группы по внедрению УПП Заказчика на днях продлило сроки обучения мастеров и конструкторов. Меня это сильно беспокоит: я рассчитывала на то, что с сентября начнется тестовая эксплуатация оперативного производственного учета. Именно во время нее может быть выявлена и устранена подавляющая часть ошибок, которые вносятся на начальных этапах. Почему важно сделать это в сентябре-октябре? Потому, что в октябре бухгалтерия сделает свой очередной квартальный отчет, и у внедренца будет только два месяца (ноябрь и декабрь) для обучения бухгалтеров и согласования всех параметров переноса данных из бухгалтерии в УПП, а также для отладки этого переноса. В январе бухгалтерия будет занята «выше крыши» отчетом за предыдущий год. Чтобы сделать все по уму времени остается мало. Так у разгоняющегося самолета может оказаться слишком короткой полоса для разбега из-за не набранной во время скорости. «Взлетит» ли проект?!
Уже начало осени, и начало делового сезона для внедренцев. Теперь у меня будет больше загрузка по работе и меньше времени на написание статей. Следующую часть хроник я напишу не скоро. Но она обязательно будет. До встречи!
Заседание рабочей группы по внедрению УПП Заказчика на днях продлило сроки обучения мастеров и конструкторов. Меня это сильно беспокоит: я рассчитывала на то, что с сентября начнется тестовая эксплуатация оперативного производственного учета. Именно во время нее может быть выявлена и устранена подавляющая часть ошибок, которые вносятся на начальных этапах. Почему важно сделать это в сентябре-октябре? Потому, что в октябре бухгалтерия сделает свой очередной квартальный отчет, и у внедренца будет только два месяца (ноябрь и декабрь) для обучения бухгалтеров и согласования всех параметров переноса данных из бухгалтерии в УПП, а также для отладки этого переноса. В январе бухгалтерия будет занята «выше крыши» отчетом за предыдущий год. Чтобы сделать все по уму времени остается мало. Так у разгоняющегося самолета может оказаться слишком короткой полоса для разбега из-за не набранной во время скорости. «Взлетит» ли проект?!
Уже начало осени, и начало делового сезона для внедренцев. Теперь у меня будет больше загрузка по работе и меньше времени на написание статей. Следующую часть хроник я напишу не скоро. Но она обязательно будет. До встречи!
Получить бесплатную консультацию
* внесенные данные являются конфиденциальной информацией и не будут переданы третьим лицам