Это попытка рассказать об итерационной технологии внедрения на живом конкретном примере. Один раз в неделю Заказчик присылает свою базу и вопросы по ней, на один час автор связывается со IT-специалистом клиента по Skype и консультирует его. Прошло два месяца. Результаты перед вами.
УПП Хроники малобюджетного внедрения Часть 1
УПП Хроники малобюджетного внедрения Часть 2
Итоги предыдущей работы
«Скоро сказка сказывается, да не скоро дело делается» — так коротко можно резюмировать то, что удалось сделать за это время. И дело вовсе не в том, что не хватало большой группы внедренцев, которые, навалившись разом, всю работу бы да ка-ак сделали! Все намного прозаичнее: отпуска и болезни сотрудников, курсы повышения квалификации, прокладка локальной сети, апгрейд компьютеров…Текущая жизнь во время внедрения не останавливается. И подготовка проекта часто далека от идеала. Обычное внедрение чем-то напоминает «квест»: свои злодеи, неожиданные препятствия и подарки судьбы, переход на новый уровень только после прохождения уровня предыдущего.
Определив приоритетом текущей работы внедрение производственного учета, с начала июля 2012 сделано следующее:
- Подписаны приказы об обучении мастеров и конструкторов-технологов. Обучение затянуто из-за периода отпусков. Предполагалось, что с начала сентября мастера производственных участков все документы начнут оформлять в УПП. Но мастера, в основном, избегают обучения, ссылаясь на занятость. С конструкторами обучение идет легче. В процессе обучения ведется Лист учета. По нему сразу видно, кто думает, что процесс внедрения УПП может заглохнуть. На планерке генеральный директор огласил фамилии таких «мудрецов» и пообещал свое особое внимание к ним.
- Идет формирование контрольного примера по документообороту для одной продукции. Уже ясно, что нужны Заказы покупателей, Заказы на производство, Задания на производство, Отчеты производства за смену, Требования-накладные и Перемещения товаров.
- Идет формирование справочника Номенклатура. Сначала номенклатуру просто перегрузили из Бухгалтерии. Потом из вышестоящей организации прислали свой вариант видения группировок номенклатуры. После общения с конструкторами появился третий вариант подхода к формированию справочника. Все отстаивают свое мнение. А внедренцу остается только вспомнить, что ответило армянское радио на вопрос: «Можно ли изнасиловать женщину в центре Еревана? Нельзя, советами замучают.»
Но со справочником Номенклатура нужно что-то решать. Впрочем, кроме группировок есть и другие вопросы по этому справочнику.
Продукция, пакет или комплект?
Часто продукцию, занимающую в собранном виде много места, отгружают заказчикам в виде пакетов деталей. В нашем случае отгрузка состоит из нескольких таких пакетов, которые, в свою очередь, тоже формируются из нескольких пакетов-полуфабрикатов. Поэтому напрашивается мысль использовать для продукции и полуфабриката предыдущего передела тип номенклатуры «набор-комплект» или «набор-пакет».
Отличаются они тем, что если в документе «Реализация товаров и услуг» будет указана номенклатура с типом «набор-комплект», то списываться со склада будет не она сама, а ее комплектующие. Для номенклатуры с типом «набор-пакет» в документе «Реализация товаров и услуг» при подборе будет указана не сама номенклатура, а ее состав. Мы должны указать в документе «Реализация товаров и услуг» наименование конечной продукции, поэтому «набор-пакет» нам не подходит. Кроме того, «набор-пакет» в Заказы покупателей вообще входить не должен. Об этом говорит служебное сообщение: «Наборов-пакетов здесь быть не должно!».
Поэтому нам ближе «набор-комплект».
Но сначала мы обнаруживаем, что «набор-комплект» не может входить в другой «набор-комплект». При попытке записать его в комплектующие выдается служебное сообщение: «Комплектующая не может быть набором-комплектом!»
Оставляем «набором-комплектом» только конечную продукцию. Но теперь обнаруживаем, что становится сложно просмотреть и проверить ее состав. Обработка Конструктор спецификаций, который легко делает разузлование многопередельной продукции, комплектующие «не видит», и других методов просмотра нет. Во-вторых, при попытке создать Заказ покупателя на такую продукцию, документ пытается обращаться именно к цене комплектующих, так как начинает выдавать сообщения «В строке номер «1» табличной части «Состав набора»: Не заполнено значение реквизита «Цена»! В строке номер «2»»… и так далее.
Вот и получается, что «при всем богатстве выбора другой альтернативы нет». И для продукции, и для полуфабрикатов устанавливаем тип номенклатуры «Товар». А обработкой Конструктор спецификаций проверяем состав Продукции №1, на основе производства которой и будет сделан контрольный пример.
Характеристика на номенклатуру
«Характер нордический, стойкий. Беспощаден к врагам рейха.» — такова была характеристика на Штирлица.
У нашего клиента одно и то же изделие изготавливается из стали разных марок. Нужно ли использовать характеристики номенклатуры?
В 2002 году фирма «1С-Рарус» разрабатывала специализированное решение для мебельных предприятий. Тогда разработчики столкнулись с ситуацией, когда для одной модели дивана может использоваться до 1600 разных тканей. Создавать такое количество элементов номенклатуры потенциальные пользователи не соглашались: диван-то один. Выходом из сложной ситуации послужило создание и учет по дополнительным характеристикам номенклатуры. Теперь типовые конфигурации КА и УПП имеют эту возможность.
Но если характеристик две-три, а производственный процесс сложен, то можно по-прежнему создать разные элементы номенклатуры и не включать флаг «использовать характеристики номенклатуры». Тем более, что учет по характеристикам и расчет себестоимости по характеристикам настраивается в программе отдельно. К тому же для проверки правильности работы всех этих хитросплетений в каждом новом релизе программы нужен именно «нордический характер».
Точность в спецификациях
«Погубят тебя слишком большие возможности», — сказал доктор Айболит Бармалею, когда тот собрался его утопить, повесить и изжарить одновременно. Предоставленные в 8-ке большие возможности использовать для одной единицы номенклатуры разные единицы измерения часто приводит к проблемам и ошибкам пользователей. В нашем случае они (пользователи) их не миновали.
Вот полуфабрикат Закладная деталь ЗД1 (см.скриншот Закладная деталь). Не знаю, как у вас, но мое «шестое чувство» заставляет насторожиться при виде этих единиц измерения. Сколько весит эта деталь? Самое длинное число коэффициента пересчета в штуки указано для тонны.
В карточке единицы измерения «тонны» для Закладной детали ЗД1 мы опять видим тонны. Что за «масло масляное»? Просто есть меры веса и объема, которые указываются в Настройках параметров учета -> Печать, единицы измерения и используются в ТТН (см. скриншоты Вес в параметрах учета и Тонны и литры). И распространенные ошибки в использовании разных единиц для номенклатуры состоят в том, что либо не указывают коэффициенты пересчета из одной единицы в другую, либо путают единицу веса, установленную в параметрах учета и единицу измерения для номенклатуры.
Чтобы не переходить в тысячные доли лучше «укрупнить» вопрос: сколько весят 100 деталей? Чтобы не считать каждый раз заново, лучше ввести такую единицу измерения сначала в Классификатор единиц измерения подбором из ОКЕИ, а потом в справочник.
1*100/ 1492,537= 0,067 т
Вносим в справочник найденное значение. Для более мелких деталей можно вносить вес 1000 шт. и более.
Теперь переходим на вкладку Спецификации (см. скриншот Спецификация на Закладную деталь). Так и есть, чувство не обмануло: из 0,67 кг арматуры получают 1 кг Закладной детали. Вывод: возможно в спецификацию должно входить что-то еще. Но найденный ранее вес 100 деталей говорит о том, что с весом все верно. Тогда ошибка в том, какую единицу измерения указали для спецификации: нужно указывать 1 шт, а не 1 кг. Случайность?
Берем еще один полуфабрикат Бетон B15. Для него установлена одна единица измерения: «тонна». Смотрим спецификацию (см. скриншот Бетон). Заметите ли вы ошибку сами?
Теперь проверим, совпадает ли ход наших мыслей. На выходе спецификации указана 1 тонна полуфабриката «Бетон». Для его изготовления берутся материалы, масса которых при сложении даст общую массу бетона: (0,388 т + 0,835 т + 0,987 т + 0,002 т) = 2,212 т. и это еще без воды. Другими словами, меньше двух тонн бетон, выпущенный по этой спецификации, весить не может. Тогда спецификация может быть не на 1 т, а на 1 м3. Еще нужно уточнять, идет ли речь о весе влажного бетона или сухого. А если бетон отгружают покупателю, то единицей объема для ТТН нужно устанавливать не «л», а «м3».
Чтобы проверить, правильно ли составлена спецификация и пересчет в разные единицы измерения, лучше сразу сделать ОПЗС на выпуск 2-х единиц полуфабриката или продукции, и на вкладке Материалы, заполнив по спецификации, сверить данные с контрольными цифрами.
Не знаю, как вам, а мне стало немного страшно: если детально не проверить КАЖДУЮ спецификацию и единицы измерения к номенклатуре, то всегда найдутся «умники», которые спишут эти «косяки» на ошибки работы программы, и внедрение может на этом закончиться! «Титаник» может потонуть, не выйдя из гавани!
Документооборот в контрольном примере
Создание любого сложного объекта начинается с модели. Кроме моделирования в конструкторе спецификаций нам еще нужно разработать и утвердить модель документооборота на контрольном примере. Иными словами, в базе нужно создать все документы для производства одной продукции: от заказа покупателя до отгрузки. Только после создания и утверждения всеми заинтересованными лицами такой модели можно говорить о том, что процесс внедрения УПП на данном производстве будет реальным. Правильнее это делать ДО покупки УПП, на этапе предпродажного обследования.
После некоторых метаний выбрали простую продукцию, производство которой происходит в 2 передела. Именно ее полуфабрикаты я придирчиво проверяла (см. выше). И хотя ошибки в спецификациях еще исправляются, тем не менее, мы снова и снова прогоняем эту продукцию через воображаемый заказ и производство. Схема документооборота тоже претерпевает свои изменения в связи с пожеланиями головной организации и пользователей на местах. Плюс на этом примере идет обучение пользователей.
Итак, все начинается с Заказа покупателя. На основании Заказа покупателя вводится Счет на оплату покупателю и Заказ на производство (см. скриншот Документооборот). Заказ на производство может разузловать продукцию до предыдущего передела (полуфабрикатов). А Заказ на производство, введенный на основании первого Заказа на производство, разузловывает полуфабрикаты уже до покупных материалов. Тогда можно делать Заказ поставщику. Конечно, в реальном варианте Заказы поставщикам будут делаться обработкой Помощник планирования, так как она позволит обрабатывать много Заказов на производство и делать Заказы поставщику для многих контрагентов.
В начале встречались трудности: у пользователей не заполнялся Заказ поставщику. Причина была проста: сначала создали документы ОПЗС, а потом пытались автоматически заполнить Заказ поставщику. Пришлось показывать отчет о движениях этих документов и объяснять, что в регистр «Потребности заказов на производство» документ Заказ на производство пишет Приход, а документ ОПЗС пишет Расход. Если потребности отсутствуют, то и Заказ поставщику заполняться не будет.
Неприятие вызвало то, что в Заказе поставщику не всегда происходило сворачивание строк с одинаковой номенклатурой. Пришлось объяснять, что в табличной части документа такое повторение обусловлено рядом причин, но в печатной форме к этому документу сворачивание по номенклатуре произойдет обязательно.
В общем, опасения постепенно идут на убыль: производство клиента действительно вписывается в схему стандартной конфигурации УПП. А учредитель требует с нового года перевести работу всех служб в единой базе на основе УПП.
Что предстоит сделать
Заседание рабочей группы по внедрению УПП Заказчика на днях продлило сроки обучения мастеров и конструкторов. Меня это сильно беспокоит: я рассчитывала на то, что с сентября начнется тестовая эксплуатация оперативного производственного учета. Именно во время нее может быть выявлена и устранена подавляющая часть ошибок, которые вносятся на начальных этапах. Почему важно сделать это в сентябре-октябре? Потому, что в октябре бухгалтерия сделает свой очередной квартальный отчет, и у внедренца будет только два месяца (ноябрь и декабрь) для обучения бухгалтеров и согласования всех параметров переноса данных из бухгалтерии в УПП, а также для отладки этого переноса. В январе бухгалтерия будет занята «выше крыши» отчетом за предыдущий год. Чтобы сделать все по уму времени остается мало. Так у разгоняющегося самолета может оказаться слишком короткой полоса для разбега из-за не набранной во время скорости. «Взлетит» ли проект?!
Уже начало осени, и начало делового сезона для внедренцев. Теперь у меня будет больше загрузка по работе и меньше времени на написание статей. Следующую часть хроник я напишу не скоро. Но она обязательно будет. До встречи!
P.S. На предприятии сменился владелец и про УПП все забыли.
Спасибо за «вести с полей». С интересом читаю Ваши статьи ! Если программировать в 1С можно научиться по книжкам и интернету, то опыт внедрения систем учета приходит только с опытом. Не брасайте нас (будущих внедренцев) ждем новых Хроник.
(0) Да, здо’рово !!! (эмоциии… 🙂 )
Это нечто новое назревает! Как по каналу Дискавери, когда показывают фильм, как последовательно строился тот или иной объект-здание: как вовремя не подвезли материал, и другие оргвопросы. Настоящее реалити-прожект.
Я полагаю, что к этому проекту в скором времени можно будет подключить и нас — зрителей. Представляете, под вашим руководством еще 10 или 30 программеров или консультантов-волонтреов или за плату скопом накинутся на задачу? 🙂
Присоединяюсь автору и к комментариям, поучительно… ))))))
p.s. «Пилите, Шура, пилите… они внутри ЗОЛОТЫЕ «© Золотой теленок
Если будет что сказать, то было бы интересно помимо производственных вопросов осветить и межличностные телодвижения(если таковые всплывают): мужской шовинизм, снисходительное пренебрежение (чего ты, мол, ты тут? мы и сами всё знам); а также саботаж, палки в колёса и проч. Спасибо.
Присоединяюсь к комментариям, познавательно.
При этом хорошо еще когда пользователи обучаемы, а руководство «внемлет».
А то иногда околоруководящие товарищи действительно готовы потопить «титаник», лишь бы показать что сами все знают лучше и не собираются что то менять. согласна с zzz_natali что межличностные телодвижения иногда весьма тормозят процесс. Интересно как автор их обходит если таковые встречаются?
(5) shekl, (4) zzz_natali,
ВАУ! Я же по образованию психолог! Спрашиваете за «межличностные телодвижения»? Их есть у меня… Вот только со временем сейчас может быть напряг. А как-нибудь обязательно. Запасайтесь попкорном!
грустные прогнозы ,может не взлететь.
(7) PiccaHut001,
Да, может. Или взлетит «авралом», а потом «в полете» будут «допиливать напильником». И это грустно.
Спасибо за статью — ждем продолжения. Только просьба — вставляйте ссылки на предыдущие статьи.
(9) EfiopReal, так вот же они все —
Спасибо огромное за интересные статьи, причём интересные не только с точки зрения предметной области, но и тем, что написаны живо и талантливо.
Да, Ваше внедрение — типичный подход франчи.
Таким образом они не один проект завалили.
Я еще в первой части писала:
— Тратить больше 15 минут (ВСЕГО, а не в день) на обучение — бесполезно
связь между справочниками, документами и отчетами» пользователь или поймет сразу, если знает суть своей работы, или поймет в процессе работы или не поймет никогда.
Расчет на «умных» пользователей бесполезен.
Конечно, так затягивать обучение Вам выгодно: работа легкая, оплата почасовая.
Я вот закупили пакеты «Умное предприятие». По производству там есть такие книги
Производственные отделы
11 Рабочее место Конструктора, технолога, нормировщика 1.3.28.1
12 Рабочее место Специалиста ПДО 1.3.28.1
13 Рабочее место Экономиста производства 1.3.28.1 + РАУЗ
14 Рабочее место Учетчика производства 1.3.28.1
и вперед!
Кто будет возникать, что его не обучали — книжку в зубы.
Особо вредным — книжку с дистанционным обучением.
(9) EfiopReal,
Уважаемый Эфиоп Настоящий! В подвале каждой статьи есть ссылки на все предыдущие статьи автора. Поэтому дополнительные вставки я посчитала избыточными.
(11) margo2007,
Таким образом они не один проект завалили.
Ничего, что мы — фрилансеры?! И то, что по нашей вине не было провалено ни одного проекта?!
«Легкая работа» — это когда
А вот обучить, даже если плохо обучается… попотеть и поскрипеть мозгами приходится. Иногда до обучаемого «плохо доходит» не потому, что он — глупый, а потому, что или нет мотивации (тогда ее нужно создать), или твой словарный запас не из его лексикона (тогда нужно подбирать другие слова).
Оплата почасовая, но клиент может расторгнуть договор в любой момент. Поэтому он должен чувствовать, что с нами ему лучше, чем без нас. И тут попотеть приходится тоже.
А с Вашей агрессией к обучаемым можно работать только фикси. Только там это «проканает».
Поэтому Вам важен процесс, а мне — результат.
3 месяца — результата нет.
К стати, как там у них с текучкой? Сколько людей из Ваших обучаемых уволилось?
margo2007
я фикси, но даже у меня никто не уволился, тоже идет внедрение БП малыми шажками
по статье как раз видно — результат есть, люди втягиваются
(14) margo2007,
Ошибаетесь, уважаемая. Это Вам платят за процесс пребывания на рабочем месте. А нам — только за часы результативной работы. Просто Вы уже поднаторели в поиске виноватых, причем виноватым может быть кто угодно, только не Вы. А, следовательно, сотрудничать (т.е. работать сообща) с Вами проблематично. Так что причина провала проектов может быть ближе, чем Вы думаете.
По нашему опыту знаем, что самое сложное на проекте — создание команды, объединяющей усилия работников со стороны и внутренних сотрудников предприятия.
А сколько уволилось — мы не знаем. Мы-то консультируем на этом проекте только ИТ-специалиста клиента.
PAVI
поделитесь опытом как часто хватает типовых решений УПП для нормального функционирования предприятия?
Ведь любое производство всегда со своими «рюшечками» которые в типовое решение не засунешь и надо что то писать..
а в нашем случае вообще не подходит. и надо писать практически с нуля.
(17) Sergey03,
«Рюшечки» есть, но не на каждом предприятии. «Переписывать с нуля» дело почти безнадежное. Иногда достаточно «загрубить» процесс производства.
Можем попробовать вместе составить модель на Ваших данных. Тогда будут ясны риски.
«Загрубить» -значит подстроить производство под программу, не каждый руководитель на это пойдет.
наоборот хочет что бы программа прогнулась:) под производство. Например нужна поэтапность производства, что бы последующий этап без предыдущего не вводился. На каждом этапе ЗП от сделки начислялась..
Спасибо за статью, всегда их читаю с удовольствием.
Самое главное, чтобы руководство понимало проблемы внедрения, т.к. некоторые вопросы можно решать только организационными методами: это и обучение, это и взаимотношения между отделами
Занятно.
1. Единой методологии (или методики? — путаюсь) — пока не видно. Каждое внедрение уникальным получается. То есть — чистое шаманство. Что, собственно, и уводит нас от декларируемых «внедрений» к нормальному и понятному «работаем как получается, получится — назовем внедрением, не получится — ну мы особенно об этом трубить не будем».
2. «На основании Заказа покупателя вводится Счет на оплату покупателю и Заказ на производство» — это частный случай именно здесь или как? а то я сразу представляю себе, что запущена производственная линия, а клиент счет не оплатитл…
(21) тихий бред. РУКОВОДСТВУ совершенно пофиг «проблемы внедрения». Рукводству надо чтобы (упрощенно) контора работала и шло бабло, причем чтобы контор а работала поменьше, а бабло шло побольше. «Внедрение» здесь — лишь инструмент чтобы либо работать поменьше (в итоге), либо бабала будет капать побольше (в итоге).
> поделитесь опытом как часто хватает типовых решений УПП для нормального функционирования предприятия?
— для нормального и ниже нормального функционирования предприятия обычно хватает типовых УНИВЕРСАЛЬНЫХ решений. Залог эффективное функционирование предприятия — специализация (в т.ч. и отход от универсальных программных решений). Ну и ЛЮДИ — без них никуда. в первую очередь они являются залогом эффективного функционирования.
(22,23,24) CheBurator,
Лихо Вы со всеми…
1. Что касается методологии (методики)- есть модули УПП, есть сроки, оптимальные для внедрения некоторых модулей, есть общие принципы обучения и разные методические материалы в помощь. Все это повторяется из проекта в проект. Есть особенности кадрового состава предприятия и его бизнес-процессов — это уже нюансы, которые не повторяются ни на одном проекте. Поэтому каждое внедрение и типовое и уникальное одновременно. Без этого понимания на проекты не спецов, а роботов можно запускать. Или писать подробное руководство и отправлять внедрять кого-угодно.
2.На основании Заказа покупателя действительно надо вводить и Счет на оплату покупателю, и Заказ на производство. Вот только в описании бизнес-процессов конкретного предприятия придется указать, кто и в каких случаях может вводить Заказ на производство даже при неоплаченном Счете (бывает и такое).
3.»Тихий бред» получится, если
К сожалению, без управленческого рычага внедрение невозможно. О столкновении интересов разных служб на проекте уже было не раз говорено. Хотя итоги выведены общо, но верно.
4. Про 24 пост я в замешательстве: по форме все верно, но смысл размыт…
(22) CheBurator,
Именно так у меня. Мало этого, мы и счета-то выставить не можем до окончания производства.
Существуют методики (не методологии) обучения юзеров. Методологию внедрения можно разработать, если есть методология учета (хотя бы затрат). Т.е. методология внедрения — это набор правил/приемов натягивания типовухи на бизнес. В реальности же внедренцам проще натягивать бизнес на типовуху — ну, а там методологии не требуется.
(25) по (24) — а все просто. универсальные решения — они типа плоскогубцев — ими и гайку закрутить/откуртить можно (правда шлицы/ребра гайки сорвать можно) и маленький гвоздик забить (но плоскогубцы в итоге заклинит), а при сноровке — плоскогубцами можно даже брови выщипать (главное глаз не выбить случайно попутно)… Спрашивается — а фиг ли мы все плоскогубцами делаем..? ответ? а потому что в обозримом пространстве спецов, которые будут куртить гайки наборами хромированных ключей и получать за это 5 копеек — не видно… и опять же — если нам надо всего гвоздики забить — может ну его нафиг плоскогубцы — специализированный молоток дешевле и эффективней…
Автору спасибо. Чужой опыт внедрения всегда на пользу.
У нас есть одна фирма, которая обучает пользователей на местах довольно эффективно. Вот только телефончики бы им надо отключать на это время, а то клиенты звонят.
Другая солидная фирма (франчайзи 1С) взялась переделать УПП под специфику нескольких предприятий одной отрасли. В результате на курсах в последний день обучения специалистов им преподносят именно эти изменения. Специ фирмы пытаются выдать себестоимость «на гора», но получается какая-то чушь. Для слушателей курса было корректно сказано: «Извините, но в процессе обучения кто-то из специалистов ошибся. Ситуация будет проанализирована, проект доработан». Результат: проект, к сожалению, не был внедрен ни на одном из предприятий отрасли. Отрицательный результат — тоже результат. Денег жалко, однако.
(28) kng67,
Очень интересуюсь отраслевой спецификой. Если можно подробнее, то дам контакты.
(13)
У Вас очень грамотный подход к внедрению, но есть нюансы:
1. Не стоит кичиться тем, что нет ни одного провального внедрения — это, как кажется, наоборот минус. Не зря же народная пословица гласит, что за одного битого двух небитых дают. По этому поводу мне нравиться выражение Билл а Гейтса — «Успех — паршивый учитель. Он заставляет умных людей думать, что они не могут проиграть». Лично я имею одно проваленное внедрение УПП и этот опыт, для меня лично, гораздо более ценен, чем все успешные вместе взятые.
2. Обучение в наибольший степени зависит от мотивации сотрудников, а обеспечить мотивацию сотрудников можно только админ ресурсом. Лично я очень часто применяю систему аттестации сотров и по результатам могут быть санкции в плоть до увольнения. Это конечно обговаривается с руководством.
3. В обучение применяю собственные видеоуроки, записанные под клиента на его базе.
4. Наиглавнейшим моментом в подготовке к внедрению, считаю разработку качественной функциональной модели учетной системы – это и у вас так, как я понял – это хорошо. Но, разработать оптимальную модель не будучи программистом, считаю практически не возможно, потому что методист не в состоянии оценить уровень сложности доработки и всегда пытается решить вопрос обходным путем – без программирования. А иногда это приводит к излишней громоздкости модели. Например, необходимость указания цен в табличной части «состав набора» для номенклатуры с типом «набор-комплект» решается в течении 3-5 минут небольшой программной доработкой. Так же, для внедренца УПП, на текущий момент, просто обязательным является знание СКД и умение настраивать отчеты на СКД и обучение этому пользователей (это не так сложно, как кажется).
5. Ответственность за успех внедрения должна телится 50/50 между внешними внедренцами и штатными сотрудниками предприятия. Иначе, штатники, просто ничего вообще не будут делать и в итоге все спихнут на внедренцев. И так будет меняться команда за командой, пока ген. диру кто-либо не объяснит, что отвечать за качество учета должны те, кто его ведет, а не только те, кто обеспечивает техническую возможность его ведения.
Вам респект и удачи!
(30) Prepod2003,
«Кичиться» не стоит ни чем, согласна. Только в провальных внедрениях мы с мужем-программистом участие принимали, но эти провалы были не по нашей вине. Кстати, и этот проект уже «заглох». Причина: акционер продал дело другому акционеру. Когда «новая метла» мести начнет — неизвестно, но команда на предприятии уже меняется. И о внедрении УПП все забыли. Вот и «здрасьте».
Спасибо за пожелания.
Как успехи, доживу ли до следующего выпуска? ))))
Читать все не стал, но сама задумка классная. Авторам + однозначно!