Проблемы внедрения 1С:ERP на крупном предприятии

Управление - Управление проектом

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

Сегодня я хочу поделиться опытом выполнения большого проекта, с какими трудностями я на нем столкнулась, как их решала и какие выводы сделала на будущее.

Для начала о самом проекте: внедрение 1С:ERP на промышленном предприятии. Когда мы пришли к клиенту (в 2015г), численность завода составляла 5 тысяч человек. За время проекта завод существенно вырос и нарастил объемы производства, сейчас на нем работает порядка 6,5 тысяч сотрудников. 1С установлена на 1,2 тыс. рабочих мест. Активно работающих пользователей сейчас (июнь 2017г) порядка 350, планируется увеличение до 450ти.

Предприятие входит в военно-промышленный комплекс России, и, следовательно, имеет свою специфику.

До этого проекта я запускала средние предприятия (1000-1500 сотрудников, 50-150 рабочих мест). Делать их мы уже научились, выработав четкую методологию (сейчас у меня с командой среднее время перевода проекта в промышленную эксплуатацию 7-10 месяцев, в зависимости от его сложности.)

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

Итак, по порядку. На завод мы пришли в конце 2015г. Изначально стояла задача запуска регламентированного учета. По ходу функционального моделирования руководство Заказчика (с подачи главного бухгалтера) приняло решение о передачи функции ввода первичных документов «на места». Границы проекта были пересмотрены, включив в себя центральные склады, кладовые, цеховую бухгалтерию, управление договорами и БДДС. Сроки внедрения регламентированного учета были сдвинуты на 2017г, а в течение 2016г автоматизировалась «первичка».

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

Если честно, то я думала, что главной сложностью будет саботаж со стороны пользователей. До внедрения 1С те ничего никуда централизованно не вводили: кто-то работал в Excel, кто-то - в самописных системах. Основой документооборота были «бумажки», которые потом сдавались в АСУП для ввода операторами в бухгалтерскую программу. Здесь проектная команда со стороны Заказчика грамотно подошла к вопросу – был выпущен ряд приказов, подписанных генеральным директором, которые закрыли проблему. Приказы оформлялись не в привычном стиле «на нашем предприятии запускается система…», а были вполне конкретными «с такого-то числа бухгалтерия принимает от складов только документы, выписанные из 1С». Для снятия возможного недопонимания мы сразу включили штриховое кодирование документов и раздали бухгалтерии сканеры (реально были попытки сдать документы, «нарисованные» людьми в Word).

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

Первая (хотя и не основная) проблема была вполне предсказуема – это объемы данных. Однако масштабы ее я изначально недооценила. Для примера – просто загрузка (безо всякой обработки) остатков по «малоценке» занимает около 4х суток. А если по итогам вдруг обнаруживаются расхождения, то еще четверо суток, а потом еще.… То есть этот этап работ надо при планировании очень тщательно прорабатывать вместе с заказчиком, буквально по дням. Например, здесь мы пошли по обычному пути: загрузили только справочники и посадили пользователей бить «первичку», чтобы после окончания загрузки остатков, все провести, проверить и выйти на оперативный учет. В итоге мы физически не успели до конца месяца свести учет и начислить погашение стоимости, и чтобы сдать управленческую отчетность, пришлось руками переносить из старой системы суммы затрат, а потом их корректировать из-за разных методик учета.

Так же многих нужных данных в нормальном виде у заказчика нет, и соответственно просить их подготовить надо сильно заранее: например, список открытых заказов нам начали собирать за три (!!!) месяца. Казалось бы, чего уж проще? Предприятие должно владеть информацией, что кому и когда оно должно произвести и отгрузить. Но, как оказалось, в формализованном виде у них были только номера заказов (требование по организации раздельного учета по Гособоронзаказу), а наименование продукции, количество, сроки и т.д. хранились либо где-то в Excel, либо в бумажных договорах.

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

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

Также большое количество «первички» повышает стоимость ошибок: если ты вдруг забыл о заполнении какого-то реквизита или научил заполнять его неправильно (что, к сожалению, случается), то никак не получится «быстренько все прошерстить руками». В лучшем случае правильно заполненные данные ты получишь со следующего месяца. То есть на таких проектах можно использовать только очень опытную проектную команду – «косяки» новичков можно просто не суметь исправить.

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

Отдельно стоит упомянуть организацию информирования пользователей программы. Надо заранее встраивать в конфигурацию модули для вывода обязательных сообщений: обзвонить 350 человек и сказать, что обновилась инструкция или что сегодня будет запускаться расчет себестоимости, нереально. Здесь нам сильно помогла заплатка из БСП (библиотека стандартных подсистем).

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

Как я работала до этого: по каждому процессу определялся его Владелец, который формировал по нему требования, мы разрабатывали схему работы, проходились по ней с ключевыми пользователями, после чего утверждали у владельца. Обычно такая методика хорошо закрывает 80% операций, а оставшиеся 20 «подрихтовываются» на этапе опытно-промышленной эксплуатации. По этому пути мы пошли и здесь. Разница между реальностью и представлениями руководителей отделов проявилась практически сразу же. Но начальники говорили «не может быть!», а подчиненные в силу корпоративной культуры им не возражали. В итоге утвержденная схема работы содержала часть слишком трудоемких операций, много избыточных контролей и не содержала определенного количества того, «чего у них точно не бывает». Все это пришлось переделывать в ходе опытно-промышленной эксплуатации. Уже реализованные и сданные доработки в итоге были кардинально переписаны, а сама ОПЭ потребовала постоянного присутствия программистов.

К проблеме «размазанности» знаний о каждом процессе между десятками людей, добавилось большое количество, вроде бы, однотипных отделов (только центральных складов у них порядка 30), которые при схожести функций, имели свою специфику и свои особенности учета – а это значит, что даже одинаковые операции могут выполняться несколькими способами. Лозунг «унификация процессов», заявленный на старте проекта, умер в ходе первого боевого запуска.

Анализируя, по итогам, проект, я пока не вижу способа особо снизить риск значительного расхождения между описанными процессами и реальностью: чтобы подробно проработать схему с каждым подразделением, а потом еще – с их руководителями, бюджет Функционального моделирования придется увеличивать в 5-7 раз, а заказчикам обычно сложно понять ценность данного этапа и заплатить 25% от стоимости проекта просто за «бумажку». Была мысль о тестовом прогоне системы на нескольких подразделениях, которую я попробовала на другом проекте, но в полной мере она себя не оправдала.

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

Третья проблема проекта вытекает из первых двух: большое количество пользователей (для которых нужно много консультантов) и большое количество проектных решений, которые принимаются прямо на этапе ОПЭ. А так как в ERP одну и ту же задачу можно решить различными способами, то разные консультанты используют разные методы, и в итоге система начинает «расползаться». Никакие «совещания по итогам дня» здесь не помогают, потому что из-за объема разных вопросов консультанты многое к вечеру уже просто забывают.

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

Что в итоге? Несмотря на шишки, слезы и седые волосы, управленческий блок у клиента запустили. Сейчас перешли к регламентированному. Надеюсь, что опыт, полученный на первых этапах, поможет в его запуске.

См. также

Комментарии
1. Виталий Писарев (vitaly28011971) 29.06.17 12:59 Сейчас в теме
Вера, такой вопрос.
Насколько часто при внедрениях используется механизм бизнес-процессов 1С?
По идее, бизнес-процессы 1С, как единые точки входа, очень хороши.
Так вот, читая статьи о внедрениях разных уровней, я не разу не видел упоминания о том, чтобы в системе, будь то УПП или уже ERP что-то решалось с помощью этого механизма.
Спасибо.
2. Анна Шульман (aselik) 23 29.06.17 13:06 Сейчас в теме
Я работаю штатным программистом на промышленном предприятии (150 человек, 40 пользователей, УПП). Чистое везение, что меня сразу посадили в один кабинет со снабженцами. В нашей системе они являются центральным звеном, связывающим весь производственный процесс от этапа разработки машины конструкторами до ее выпуска в цеху. Благодаря близости к пользователям, я смогла понять, что действительно должно быть в системе. А до меня два года УПП пыталась внедрить франчайзи и продвинулись они очень мало, именно из-за того, что никто не мог объяснить им нужды процесса. Теперь о наболевшем... Система работает, но неожиданно я столкнулась с моральными аспектами работы в программе. Можно сказать насаждается дедовщина! Управленцам хочется получать более подробные данные и они спускают пользователям указания их вносить. Т.е. пользователей, тех что побеззащитней, вынуждают вносить то, что нужно не им, а кому-то другому. Я считаю, что это неправильно: тебе надо - ты и вноси. Но они же начальство! Вот пока сопротивляюсь, отказываюсь дорабатывать программу, которая служит инструментом принуждения. Когда работала во франче, даже не подозревала ,какое зло эта 1С!
3. Евгений Шерстюк (forseil) 67 29.06.17 13:53 Сейчас в теме
(2) Неожиданно) 1С - инструмент принуждения)
Puk2; murzilka88; +2 Ответить
4. Анна Шульман (aselik) 23 29.06.17 14:00 Сейчас в теме
Таки-да! Сейчас как раз был разговор с начальством по этому поводу. "Нам же нужны данные, поэтому пусть они вносят". Плевать, что "у них" вообще-то основная задача продукцию производить, а не в программе копаться.
5. Сергей Гершкович (sereginseregin) 15 29.06.17 15:28 Сейчас в теме
По статье
... Есть несколько ключевых пользователей, которые ведут какой-то свой «кусочек» и есть руководитель отдела, который имеет свое представление о том, как они работают....К проблеме «размазанности» знаний о каждом процессе между десятками людей, добавилось большое количество, вроде бы, однотипных отделов (только центральных складов у них порядка 30)...

Отличное описание, что такое крупное промышленное предприятие от 5К сотрудников.

Вот только описание внедрения:
...сама ОПЭ потребовала постоянного присутствия программистов...Несмотря на шишки, слезы и седые волосы, управленческий блок у клиента запустили. Сейчас перешли к регламентированному.

Никак не раскрывает опыта автора по решениею перечисленных им же проблем.

...Границы проекта были пересмотрены, включив в себя центральные склады, кладовые, цеховую бухгалтерию, управление договорами и БДДС...остатков по «малоценке»...список открытых заказов...

Хотелось бы конкретики по результатам внедрения о распределении ролей, количестве пользователей, объеме регистрируемых в системе данных по направлениям.
6. Зу Темирова (Zabava_) 10 29.06.17 17:47 Сейчас в теме
(4) тут как раз отразилось Ваше тесное сотрудничество с пользователями. :))
Считаю, что Вы неправы. Учетная система внедряется как раз для анализа полученных данных. И вариант "тебе надо, ты и вноси" звучит очень странно :) Бюрократию разводить конечно не стоит, но если руководителю для анализа состояния компании требуется дополнительная аналитика, то он должен ее получить. Иначе рискуете вообще лишиться компании и следовательно рабочих мест. Посмотрите на ситуацию с этой стороны.
chng; VanWilder; PAVI; +3 Ответить 1
7. Игорь Маркелов (igomark) 29.06.17 18:46 Сейчас в теме
(2) Анна, я бы тоже не был так категоричен относительно "тебе надо -
ты и вноси". В идеале данные должны вноситься там, где они возникают. Но - однократно. В моей практике был случай, когда руководство требовало от рядовых пользователей вводить исходные данные, а от менеджеров - помесячные суммы по этим же(!) данным. потом вылезали нестыкушки. Насилу нашли причину и убедили руководство считать суммы по уже введенным ранее данным.
Ящеен; PAVI; +2 Ответить
8. Анна Шульман (aselik) 23 29.06.17 22:00 Сейчас в теме
(6) Спасибо за совет! Просто есть работники производственного отдела, а есть финансово-экономического. И те, и те обычные рядовые сотрудники, но почему-то финансисты так заняты-так заняты, что вносить данные не могут, а данных им нужно все больше и больше. Ну и тут у них возникает спасительная идея - вносить данные в месте их возникновения, естественно чужими руками. И там где документ вносился за 5 минут, уже нужно потратить полчаса-час. Если не умерить их аппетиты, то производственники не будут успевать свою основную работу делать.
9. Илья Иванов (ИльяЕвгеньевич) 30.06.17 00:13 Сейчас в теме
(8)обычно финансисты не заняты-заняты, а просто ближе к директору или кому то из управляющих, поэтому у них чуть больше привилегий
10. Геннадий Николаев (genayo) 30.06.17 07:59 Сейчас в теме
Подробностей маловато, в частности интересно, количество сотрудников, связанных с учетом, уменьшилось или увеличилось?
11. Алексей Новиков (Новиков) 289 30.06.17 09:47 Сейчас в теме
(2)
Я работаю штатным программистом...Я считаю, что это неправильно: тебе надо - ты и вноси.


Если вы такой грамотный специалист, так прекрасно понимаете потребности бизнеса, видите его изъяны, знаете что, где, и как нужно изменить, чтобы стало лучше/прибыльней - то почему вы не управленец? Почему тупой управленец, априори пень, который насаждает дедовщину - нанял вас, дает вам задания и платит вам зарплату? Ну почему же так, поясните? Вам не кажется, что странно, если вы фикса - а это так и есть, "сопротивляться, отказываться дорабатывать программу"? Вам именно за это, буквально прямо = за ЭТО = платят деньги. Как все бывает дальше - вы раз скажите, два скажите, может быть три, а в четвертый раз вас попросят, и наймут в следующий раз человека, который не будет "сопротивляться". Вы пойдете искать новую работу. Не факт, что там будет лучше.

Мне кажется, основная проблема нашей братии в том, что оная, научившись писать код, и идя на работу, буквально писать этот гребаный код по 8 часов в день, вдруг! осознает себя чуть ли не Учредителем Группы Компаний, внезапно открывается какое-то небесное окно, сквозь которое идет ветхозаветное озарение с пониманием, что все вокруг уныло, чем более - тем полностью, все кругом - удаки, один я - Дартаньян. Да не просто Дартаньян, а заботливый, рассудительный, понимающий. И все что я говорю - это истина, которая отсыпается как благодать.

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

Вера, спасибо Вам за интересную статью. Лучиков добра вам и удачи в борьбе с темной половиной :)
denisros; Zabava_; Mopo3; VeraPikuren; Новенький_2209; Gluk_1C; +6 2 Ответить 5
12. Мироненко Андрей (andironenko) 31 30.06.17 10:04 Сейчас в теме
(11) Жестковато, конечно, но так оно и есть. ИТешник, который видит "несовершенство" мира, должен или попробовать изменить его, перестав быть ИТешником или не вмешиваться в процесс и не мешать другим работать, а заниматься тем, за что платят.

С этой точки зрения с подрядчиками работать бывает проще - у них нет стокгольмского синдрома и синдрома выученной беспомощности и, если подрядчик грамотный, он может существенно разгрести конюшни - потому что будет копать, а не сопереживать.
Zabava_; PAVI; nayd; +3 Ответить 2
13. Митя Макаревич (mitia.mackarevich) 18 30.06.17 10:28 Сейчас в теме
(12)
подрядчик грамотный, он может существенно разгрести конюшни - потому что будет копать, а не сопереживать.

в большинстве случаев после таких грамотных подрядчиков остаются "забавные решения", которые невозможно поддерживать. (плохой код, блокировки, безумная архитектура и прочее). Подрядчик и копать редко совместимо. Обычно быстрее втюхнуть, забрать бабла и свалить. О постпроекте редко кто думает
tenikov; Brawler; +2 Ответить 2
14. Anatolii Karasev (KapasMordorov) 408 30.06.17 10:37 Сейчас в теме
(11)
(12)
Дартаньяны есть и они даже пишут статьи:
http://infostart.ru/public/622937/
15. Элипсандр Эшман (ifilll) 30.06.17 11:22 Сейчас в теме
Видимо у товарища Пикурен Веры, совсем времени нет, регламентный учет внедряет, а её статьи писать заставляют.
Статья то слабая совсем, без подробностей, "экшон лишь вскользь упоминается" а "хэппи энд" не раскрывается.
Либо человека не мучайте, либо пишите много, хорошо и подробно.

Мимо Анна Шульман тоже пройти не могу, много дельного её уже сказали, но сделаю отсылку к одному персонажу, "Все лгут", надеюсь что вы меня поймете.
16. Anatolii Karasev (KapasMordorov) 408 30.06.17 11:29 Сейчас в теме
(15)
А какие еще подробности нужны?
До этого проекта (2015г.) я запускала средние предприятия (1000-1500 сотрудников, 50-150 рабочих мест).

Активно работающих пользователей сейчас (июнь 2017г) порядка 350

Вот же факты.
Или вот:
Для примера – просто загрузка (безо всякой обработки) остатков по «малоценке» занимает около 4х суток. А если по итогам вдруг обнаруживаются расхождения, то еще четверо суток, а потом еще.…
17. Элипсандр Эшман (ifilll) 30.06.17 12:05 Сейчас в теме
Более подробные подробности, конечно.

"Запускаю спутники на орбиту, очень сложно, но получается"

Хорошо, давайте посмотрим на вышеуказанный факт:
1) Почему загрузки остатков по "малоценке" занимает 4x суток? проблема технологическая? организационная?
2) Расхождения какого характера возникает? не бьется количество, суммы, строки потому что пока грузится 4х дня "малоценка" двигается, или потому что бухгалтер нашла ошибки в загружаемых данных. Почему тогда дедлайн по загрузке не определен для всех участников, грузить ведь можно до бесконечности и т.д. и т.п.
mytg; Lucechiaro; alest; PAVI; +4 Ответить 3
18. Мироненко Андрей (andironenko) 31 30.06.17 12:28 Сейчас в теме
(13) так я же написал - ГРАМОТНЫЙ подрядчик.

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

Сделать плохо на первом этапе - это значит создать себе проблемы дальше.

И "соскочить" тут не получится - такие большие проекты сопровождаются существенными договорными условиями - просто так не откажешься.
19. Мироненко Андрей (andironenko) 31 30.06.17 12:30 Сейчас в теме
(17) это уже затрагивает коммерческую информацию заказчика, которая выходит за рамки статьи. Все материалы мы согласовываем.
20. Митя Макаревич (mitia.mackarevich) 18 30.06.17 14:01 Сейчас в теме
(18) Все я прекрасно понимаю. Есть такая штука называется "бюджет проекта". Она обычно и подводит (рано истощается). Справедливо заметить если подрядчик не грамотный. Знаете грамотных единицы попадались. К тому же копаться в конюшне за тот же бюджет, если увеличения стоимости не будет(к примеру собственник не согласовал) , никто не станет. Вы так говорите будто грамотный это правило, а на самом деле исключение.
21. Геннадий Николаев (genayo) 30.06.17 14:27 Сейчас в теме
(11) Так то оно конечно так, но иногда заведомо видно, что реализация "хотелок" руководства не приведет к желаемому эффекту, а затраты на реализацию будут значительными. И тут уже только опыт "штатного программиста" помогает убедить руководство в этом. Ну а если убедить не удалось - это опять же проблемы руководства, что дорогие ресурсы программиста будут потрачены впустую...
22. kolya_tlt kolya_tlt (kolya_tlt) 11 30.06.17 15:12 Сейчас в теме
(0) (19) Добрый день!
Есть ли у вас работа на удалёнке для разработчиков 1С или все сидят у заказчиков?
23. Евгений Грибков (1СERP) 1112 30.06.17 15:39 Сейчас в теме
(13)
Я бы не обобщал. И после фикси и фри, бывает, я прихожу на предприятие и вижу полный бардак в проекте внедрения.
Не от формы "подрядчик/НЕподрядчик" это зависит, а от экспертизы человека или команды.
PAVI; Gluk_1C; mitia.mackarevich; +3 Ответить
24. Евгений Грибков (1СERP) 1112 30.06.17 15:41 Сейчас в теме
(15)
Александр, автор столкнулась с новыми для себя проблемами на проекте и поделилась ими и своими выводами. Если Вам недостаточно подробностей - напишите, что Вы хотите увидеть. Если сможем - дополним информацию.
25. Евгений Грибков (1СERP) 1112 30.06.17 15:43 Сейчас в теме
(17)
Хорошо. Попрошу Веру написать подробности.
26. Евгений Грибков (1СERP) 1112 30.06.17 15:44 Сейчас в теме
27. Алексей Новиков (Новиков) 289 30.06.17 16:41 Сейчас в теме
(21) Вы сознательно как бы "вместоменя" что-то сказали и теперь опровергаете. Коллега описала конкретный ее личный случай "Я считаю, что это неправильно: тебе надо - ты и вноси" ©. Про какой здесь опыт "штатного программиста" ведется, простите, речь?
28. Игорь Фелькер (Brawler) 324 30.06.17 18:31 Сейчас в теме
(11)
Про принципы приема на работу описанных вами руководителей рассказывать надо и кто они как правило?
А, о том как отдаются ими распоряжения?
Зачастую, отдаются такие приказы, что ... если подчинится и выполнить их, то валится вся система учета.
А почему валится?
Да потому как эти горе руководители не знают как система работает, какие у нее взаимосвязи, какие временные ограничения на выполнение тех или иных операций!!!
Зачастую сидя на обычной завшивой должности рядового программиста люди видят картину работы организации куда шире чем руководители этой организации, ну кроме нюансов (чернухи), а бывает и их.
Именно этим программистам приходится отбиваться от горе руководителей и стопорить реализацию заведомо фатальных приказов хоть и рискуя попасть под горячую руку.
29. Геннадий Николаев (genayo) 30.06.17 22:41 Сейчас в теме
(28) Если не смотря на предупреждения специалистов "руководители" валят учетную систему - это проблемы руководителей. А грамотный специалист без работы не останется...
30. Геннадий Николаев (genayo) 30.06.17 22:45 Сейчас в теме
(27)
Мне кажется, основная проблема нашей братии в том, что оная, научившись писать код, и идя на работу, буквально писать этот гребаный код по 8 часов в день, вдруг! осознает себя чуть ли не Учредителем Группы Компаний, внезапно открывается какое-то небесное окно, сквозь которое идет ветхозаветное озарение с пониманием


Это что, про частный случай? Ну извините...
31. Игорь Фелькер (Brawler) 324 01.07.17 21:54 Сейчас в теме
(29) грамотный специалист не будет валить систему намеренно
Накой ляд прославлять свою персону как "а это тот который завалил работу систему в фирме ООО Ромашка, не нам такие не нужны"
32. Ирина Павленко (PAVI) 1648 02.07.17 08:02 Сейчас в теме
(2)
Можно сказать насаждается дедовщина! Управленцам хочется получать более подробные данные и они спускают пользователям указания их вносить

Анна, в теории за все отвечает директор, поэтому по Вашей логике все должен вносить в систему он.
А на практике есть система "делегирования полномочий". Поэтому бухгалтер вносит данные, которые ему лично не нужны. Ему платят за то, что входит в его круг должностных обязанностей. А этот "круг" на каждом предприятии определяют немного по-разному.
Одна из "плюшек" УПП и других подобных программ - возможность вносить данные теми пользователями, которые за эти данные должны нести ответственность. И если "за эти подробности" отвечает снабженец или инженер - то он и должен вносить данные в программу.
Понятно, что степень подробности вносимых данных определяет количество занятого подчиненными рабочего времени. А вот тут и программист может пригодиться, чтобы сделать удобнее и быстрее ввод. Так что не о "дедовщине" надо думать))) Удачи!
Gluk_1C; корум; hulio; +3 Ответить 1
33. Ирина Павленко (PAVI) 1648 02.07.17 08:07 Сейчас в теме
(4)
Плевать, что "у них" вообще-то основная задача продукцию производить, а не в программе копаться.


Да, и я слышала на внедрении подобные замечания от потенциальных пользователей. Только почему-то когда внедрили-таки ввод первичной информации теми пользователями, которые ее и "рождают" (мастера смен - выработку, сдельную зарплату и простой; инженеры - запчасти и ремонты оборудования), эффективность работы и оборудования, и рабочих выросла. Странно?!
34. Ирина Павленко (PAVI) 1648 02.07.17 08:12 Сейчас в теме
(8)
но почему-то финансисты так заняты-так заняты, что вносить данные не могут, а данных им нужно все больше и больше


Сама при внедрении сидела в финансовом отделе, поэтому видела, как они вынуждены делать "на коленке" все новые и новые анализы, которые с них требует директор и акционер в кратчайшие сроки. И в это время уже не до внесения данных... Может быть, Анна, Вам нужно в этом отделе "поселиться" хотя бы на время?
denisros; rendalina; Lucechiaro; hulio; +4 Ответить
35. Ирина Павленко (PAVI) 1648 02.07.17 08:22 Сейчас в теме
что на подобных по масштабу проектах придется смириться с итерационной доработкой – просто правильно ее организовать, и сразу заложить в оценку работу программистов на всю опытно-промышленную эксплуатацию, и увеличить сроки поддержки пользователей минимум в два раза.

Да, поддерживаю. Парадокс средних и больших проектов в том, что вместе с постройкой проекта растет осознание потребностей у самого клиента на разных уровнях. И чтобы найти "консенсус" между желаниями клиента и возможностями системы требуется много дополнительно
36. Ирина Павленко (PAVI) 1648 02.07.17 08:24 Сейчас в теме
... дополнительной работы.
37. Анна Шульман (aselik) 23 02.07.17 14:02 Сейчас в теме
(35) С финансистами тоже дружу) Очень много для них сделала. Пришлось только сильно поругаться, когда экономист заявила, что статья "Расход материалов" в себестоимости заказа - это сумма оплаты поставщикам. Да-да, на полном серьезе! Она себе в экселе дублирует выписку банка и расшифровывает ее по материалам и заказам. И время от времени перекидывает в этой "выписке" крупные комплектующие с одного заказа на другой. А чтобы облегчить себе эту ручную работу, решила дать задание снабженцам, чтобы они вбивали счета на оплату в разрезе ТМЦ и заказов (хотя снабженцам из счетов нужна только сумма счета и график оплат). А потом еще, если материал пошел не на тот заказ, который в счете, то снабженец должен заходить в счет и менять номер заказа. А почему снабженцы? Ну потому что они же работают с поставщиками и это их счета. Все логично! Даже думаю, что со многими программистами этот вариант бы прокатил.
38. Геннадий Николаев (genayo) 02.07.17 19:32 Сейчас в теме
(37) Как у вас все запущено...
39. Игорь Фелькер (Brawler) 324 03.07.17 00:04 Сейчас в теме
(38) Только лишь там думаете...?
40. Ирина Павленко (PAVI) 1648 03.07.17 07:29 Сейчас в теме
(37)
Она себе в экселе дублирует выписку банка и расшифровывает ее по материалам и заказам.

А зря Вы с экономистом ругались. Определенное зерно истины в его (ее) действиях есть. давайте опустим за скобки то, что понятие дебиторской или кредиторской задолженности у экономиста обычно нет. Не будем рассуждать и о том, с НДС или без него надо учитывать затраты на материалы с экономической точки зрения.
Похожую задачу, только не для поставщика а для очень крупного покупателя мы решали на одном предприятии. Представьте:
- многолетняя торговля по заказам, заказ еще и как счет, НО
- заказы недовыполняются по нашей вине;
- заказы изменяются по желанию заказчика;
- объемы товарооборота большие;
- есть сомнения в достоверности бухгалтерских данных.
Требуется сделать сверку взаиморасчетов.
Усилиями экономистов+программиста+финансиста вышли на недоплату в 6-7 миллионов :-(
41. Ирина Павленко (PAVI) 1648 03.07.17 07:34 Сейчас в теме
Наверное можно вспомнить школу: если задача доказана двумя способами, то это повышает достоверность результата)))
42. Элипсандр Эшман (ifilll) 03.07.17 11:30 Сейчас в теме
(24) Евгений, лично мне больше интересна техническая сторона вопроса, но за всех ведь не скажу.

Каждое внедрение это тот еще триллер, и каждый раз полный открытий, всегда задаешь вопрос либо они того, либо ты, и из личного опыта, всегда сопереживаю товарищам внедренцам, много больше чем персонажам из книжек разных.

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

пардонте если что не так.
43. Анна Шульман (aselik) 23 03.07.17 14:40 Сейчас в теме
(40) Не, там вообще речь шла не про взаиморасчеты. Только себестоимость. А вот другой экономист поставил задачу грамотнее - сделать отчет, который показывает, на сколько заказ недофинансирован. У нас заказ - это порядка 3000 наименований покупных материалов. Я очень долго с ним возилась, но все-таки удалось обойтись без счетов - только накладные и счет 60.
44. Анна Шульман (aselik) 23 03.07.17 14:43 Сейчас в теме
(33) А почему эффективность работы выросла, как Вы считаете? Какой тут механизм связи?
45. Анна Шульман (aselik) 23 03.07.17 15:04 Сейчас в теме
(32)
Анна, в теории за все отвечает директор, поэтому по Вашей логике все должен вносить в систему он.


Я бы хотела как-то корректнее, наверное, сформулировать свои установки. Директору подает отчет какое-то подразделение - исполнитель отчета. Отчет использует данные, которые уже внесены работниками других подразделений в результате своей "естественной" деятельности. Пока все хорошо. А вот если исполнителю отчета данных не хватает? Как решить эту проблему? Я считаю, что в этом случае это подразделение и должно внести недостающие какие-то аналитические разрезы, а не отправлять задание по месту возникновения. Конечно, если бы это занимало 5 минут в день, то и вопросов бы не было. А если как минимум час?
Над удобством ввода, конечно, думаю и тружусь, но не все поддается автоматизации)
46. Vera 1 (VeraPikuren) 03.07.17 15:38 Сейчас в теме
(1) Добрый день, Виталий.
Мне пока нигде не приходилось использовать этот механизм.
Вроде бы сам по себе не плохой, но вот как-то нет в нем явной необходимости
47. Vera 1 (VeraPikuren) 03.07.17 15:44 Сейчас в теме
(10) Добрый день, Геннадий.
Пока количество сотрудников не изменилось. 1С еще не заменила старую ИС - в нее продолжают вноситься данные (с наших бумажек) целым отделом операторов. Когда полностью перейдем на 1С, данный отдел предполагается расформировать.
48. Vera 1 (VeraPikuren) 03.07.17 15:52 Сейчас в теме
(17) Добрый день, Александр.
Оба типа проблем.
Физически считывание файлов Excel и потом формирование документов ввода остатков занимает столько времени.
Записей с остатками - порядка миллиона. В первое погашение стоимости "1С"ка на таком количестве просто встала - пришлось допиливать.
Да, много раз загружали, потому что кто-то продолжал довносить малоценку втихоря задним числом.
Где-то в оговоренные поля выгрузили не те данные (например, вместо" счета учета" дату - причем, попадалось это в середине в файла, и "глазами" сразу не отлавливалось).
49. Vera 1 (VeraPikuren) 03.07.17 16:12 Сейчас в теме
(5) Добрый день, Сергей.
Очень жаль, что не получилось донести свою мысль. Вроде вся статья была о том, как решали проблемы и какие сделали выводы. Конкретику не писала, потому что мне не кажется особо полезной информация: "на этапе ФМ мы договорились распределять 16й счет так, а потом на ОПЭ к нам пришла зам.главного бухгалтера и сказала, что, оказывается, у них на предприятии есть еще некое положение о затратах, о котором она не знала/забыла" :).
Вся суть вопроса в том, что переделывать это все равно придется - вопрос только, куда спрятать трудозатраты.

Что я пыталась донести (возможно, для кого-то это уже очевидно, но для меня стало открытием именно на этом проекте).
1. Даже с самыми опытными и грамотными специалистами с обоих сторон не всегда получается сделать работающую "Функциональную модель". И не потому, что люди злые, а по объективным причинам.
2. К тому, что на этапе ОПЭ много придется переделывать, надо быть готовым, и сразу же закладывать это в бюджет. То есть нельзя к оценке большого проекта подходить также, как и к среднему, просто сделав поправку на количество пользователей. Как я писала в первой статье: клиенту проще один раз пережить большой бюджет, чем постоянно бегать к генеральному с пресловутыми "запросами на изменение".
50. Сергей Гершкович (sereginseregin) 15 03.07.17 18:06 Сейчас в теме
(49)Добрый день, Vera.
Статья озаглавлена правильно
Проблемы внедрения 1С:ERP на крупном предприятии
Вы прекрасно донесли до Коллег(конкурентов) о проблемах, с которыми они столкнутся на крупных предприятиях.

Но в аннотации
...поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили...


потенциальным Заказчикам Вы подтвердили: "Да, такие... и такие... проблемы мы знаем", а по всем абзацам "...мы их успешно решили..." А как Вы их решили? Закрадывается сомнение...

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


...есть еще некое положение о затратах, о котором она не знала/забыла...

На крупных промышленных предприятиях с советских времен принято разрабатывать внутренние стандарты предприятия (СТП) на все существующие процессы. Многие молодые руководители могут даже не знать о них, считая свою работу традицией, переданной от старшего поколения. Первое, что Вы должны требовать на крупном предприятии - внутренние СТП и регламенты - этого в статье я также не увидел.
корум; +1 Ответить 2
51. Ирина Павленко (PAVI) 1648 04.07.17 08:49 Сейчас в теме
(45)
Я считаю, что в этом случае это подразделение и должно внести недостающие какие-то аналитические разрезы, а не отправлять задание по месту возникновения. Конечно, если бы это занимало 5 минут в день, то и вопросов бы не было. А если как минимум час?

Да, вот в этом месте самые большие сложности.
Пока мастер отчитывается Сколько и Какой продукции выработано, Чего и Сколько потрачено, Кто и Сколько отработал (сам заполняет Отчеты производства за смену, Требования-накладные и Передачу товаров) - это его компетенция, Он и материально ответственное лицо и начальник над рабочими (может менять КТУ). - его сверхнормативные затраты времени (у нас - около часа) оправданы. Он не сможет перекладывать "ошибки" на тех бухгалтеров, которые вводили его отчеты с таблиц Excel. Тем более, что время на эти таблицы они все-равно тратили. Поэтому и сам видит и сам отвечает за свои ошибки.
Но начальнику производства и главному инженеру захотелось знать производительность каждого станка в отдельности. Время на ручной ввод с такими подробностями мог перерасти все мыслимые пределы. Стали думать о передаче информации в 1С непосредственно со станка, но не нашли спеца.
52. Мироненко Андрей (andironenko) 31 04.07.17 09:32 Сейчас в теме
(50) Всякие СТП - это плод работы разнообразных бюро стандартизации, которые появились на заводах в начале 80-х годов. Они даже в момент своего создания были весьма оторваны от реальной жизни (у меня дед был главным диспетчером достаточно крупного машиностроительного завод, поэтому пишу со знанием дела). Самый главный дефект этих стандартов - это то что они были малопроверяемы - стандарт описывал одно состояние дел, а жизнь шла иначе. Заставить его соблюдать можно было только введя массовый надзор, чего никто не делал. Более или менее решались вопросы связанные с ТБ, ОТК и допуском на территорию.

Что уж говорить о текущей ситуации - когда многие предприятия претерпели массовые сокращения, реорганизации, а зачастую и банкротство.

Фактически, внедряя информационную систему на подобных предприятиях, мы создаем эти стандарты заново - уже с учетом реального состояния дел на данный момент и на определенную перспективу. Причем, так как эти стандарты теперь закреплены в "железе", то они начинают работать, и перестают быть абстрактным документом. Хотя и тут требуется определенная добрая воля руководства, для того чтобы контролировать наполнение информационной системы.
АльфаАвтоПрограммист; Dementor; корум; Gluk_1C; PAVI; +5 Ответить 1
53. Геннадий Николаев (genayo) 04.07.17 10:21 Сейчас в теме
(51) Эта проблема решается обычно разработкой АРМ, посредством которого непосредственно рабочий/исполнитель вносит данные о выработке, простоях и т.п.
А вот удобство и надежность этого АРМ - это уже вопрос ИТ.
54. Ирина Павленко (PAVI) 1648 04.07.17 11:49 Сейчас в теме
(53)
Эта проблема решается обычно разработкой АРМ, посредством которого непосредственно рабочий/исполнитель вносит данные о выработке, простоях и т.п

Можно и так, но не всегда применимо... "Дьявол скрыт в деталях" ))) Но это уже повод к конкретной дискуссии с конкретными примерами.
55. Геннадий Николаев (genayo) 04.07.17 11:56 Сейчас в теме
(54) Ну да, это явно не тема данной статьи :)
56. Сергей Гершкович (sereginseregin) 15 04.07.17 15:30 Сейчас в теме
(52)
Всякие СТП - это плод работы разнообразных бюро стандартизации

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

...добрая воля руководства, для того чтобы контролировать наполнение информационной системы...

Можно заставить вносить в систему данные одного, двух, ...ну пятерых человек. Всю службу (100 человек) заставить невозможно. Руководитель службы всегда найдет причину, по которой он продолжит предоставлять данные в собственном формате, а не в вашей системе.

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

Другое решение, руководителю предприятия необходимо иметь (недобрую) политическую волю, поставив службу в такое положение, при котором она не сможет выполнять свои прямые (традиционные) обязанности. Хороший пример в статье:
Приказы ... были вполне конкретными «с такого-то числа бухгалтерия принимает от складов только документы, выписанные из 1С»
57. Евгений Грибков (1СERP) 1112 04.07.17 15:43 Сейчас в теме
(50)
Сергей, давайте я попробую или ответить на Ваши вопросы или же конкретизировать их.

О проблемах.

Проблема 1:
Первая (хотя и не основная) проблема была вполне предсказуема – это объемы данных. Однако масштабы ее я изначально недооценила.
Решение:
1.1. Для примера – просто загрузка...То есть этот этап работ надо при планировании очень тщательно прорабатывать вместе с заказчиком, буквально по дням.
1.2. Многих нужных данных в нормальном виде у заказчика нет... В последующих проектах мы с клиентами начинаем подготовку к переносу данных сразу же после первого этапа проекта - функционального моделирования.
1.3. Также большое количество «первички» повышает стоимость ошибок... На таких проектах можно использовать только очень опытную проектную команду – «косяки» новичков можно просто не суметь исправить.
1.4. подобные масштабы предъявляют специфичные требования к опытно-промышленной эксплуатации: обычно на простые участки (например, центральные склады) я закладываю полтора-два месяца поддержки, этого вполне достаточно, чтобы отработать блок. А здесь некоторые кладовщики начали всерьез анализировать данные в программе только через 3 месяца. То есть до этого они просто учились вносить документы в систему. Получилось, что в ходе работ по запуску уже других участков приходилось отвлекать ресурсы на поддержку закрытых функциональных блоков. Это надо учитывать при планировании людей и бюджета.

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

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


Я постарался совсем четко выделить проблемы и решения, озвученные в статье. Сергей, если описание решения Вам кажется недостаточно подробным - пишите.
58. Мироненко Андрей (andironenko) 31 04.07.17 16:02 Сейчас в теме
(56)
осить в систему данные одного, двух, ...ну пятерых человек. Всю службу (100 человек) заставить невозможно. Руководитель службы всегда найдет причину, по которой он продолжит предоставлять данные в собственном формате, а не в вашей системе.

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


Это немножко теория, давайте я Вам опишу одно из предприятий, которое автоматизировал уже я.

Завод основан в 196х году, имеет уникальные в России позиции, практически вся продукция идет на экспорт, поэтому в финансах проблем не испытывает.

Завод претерпел приватизацию и имеет 4 собственников, влияние которых примерно равнозначное. У собственников завода есть ставленники "аватары" внутри самого завода, которые активно отстаивают (в их понимании) интересы каждый своего хозяина, что приводит к регулярным склокам, подставам, блокировкам.

Основные группы влияния:

1. Гендиректор.
2. Финансовый директор.
3. Главный бухгалтер.
4. Директор по производству.

Нас на проект приглашает директор ИТ, который номинально подчинен ген. директору. Поэтому на наше предложение по автоматизации враждебно смотрит финдир., главбух, а директор по производству нас просто игнорирует. В процессе заключения договора директора ИТ "съедает" финдир (ловит на мелком откате в закупках техники).

Гендир после этого абстрагируется от процесса автоматизации, но в последний момент оказывается что договор подписан.

Проект нужно делать и я начинаю искать другие точки входа - нахожу их в финдире, который параллельно пропихивает кандидатуру своего директора ИТ.

Мы мгновенно получаем в противниках гендира, который стремится отомстить финдиру за прошлую подставу. Нас пытаются лишить финансирования, но финдир платит.

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

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

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

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

Что делать в этой ситуации подрядчику - ждать у моря погоды? Так таких предприятий (если они крупные) - 70-80%.
komatoza; Redokov; Zabava_; sharonovev; АльфаАвтоПрограммист; Dementor; sqncng; корум; +8 Ответить 2
59. Сергей Гершкович (sereginseregin) 15 04.07.17 16:20 Сейчас в теме
(57)
Евгений Грибков,
Я постарался совсем четко выделить проблемы и решения, озвученные в статье.


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

Мне кажется, форму описания решений желательно как-то подправить:
- Этапы работ ПРОРАБОТАЛИ вместе с заказчиком, буквально по дням
- «косяки» новичков не сумели исправить, НАЧАЛИ с нуля с опытной проектной командой
- программистов ПРИВЛЕКАЛИ в процессе всей опытно-промышленнуй эксплуатации
- ВВЕЛИ отдельного архитектора, который на время ОПЭ изолирован от пользователей, и через которого ПРИНИМАЛИСЬ все проектные решения
60. Сергей Гершкович (sereginseregin) 15 04.07.17 16:44 Сейчас в теме
(58)
Могли ли эти службы "договориться" и написать сами какие-либо СТП

Они же работали совместно до вас, значит договорились. Пришли ВЫ, предложили новый формат обмена данными. Вариант один, со всеми (политически) договариваться.

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


Крупное предприятие - мини государство. Вас в соавторы статье надо включить.

Что делать в этой ситуации подрядчику - ждать у моря погоды?

Закладывать в смету ;-). Я ждал в статье ответы....
61. Мироненко Андрей (andironenko) 31 04.07.17 17:04 Сейчас в теме
(60) Тут просто не бывает универсального набора решений. Только если уж совсем по верхам:
1. Нужно понимать, что у РП для крупного предприятия основная задача - это политическое продвижение проекта, а не технические задачи.
2. Существенная часть большого проекта автоматизации - это не автоматизация, а консалтинг. Нужно будет не автоматизировать что-то, а вначале разрабатывать что автоматизировать.
3. Любое проектное решение, даже согласованное и утвержденное, не гарантирует что по факту так и будет работать. ОПЭ может всё перевернуть на 180 градусов.
4. Идя в большой проект не стоит идти туда с маленьким бюджетом, в надежде переверстать бюджет в процессе работ - процесс согласования дополнительных суммы эквивалентен по сложности заключению самого договора. То есть лучше вложиться в продажу проекта один раз за 50 млн., чем также вкладываться каждый раз за дополнительные 300-500 тысяч. На больших проектах маленькая цена не преимущество, а источник проблем для всех участников сделки.
5. Реально большой проект сложно сделать без помощи и вмешательства 1С. Лучше позаботиться об этом заранее - хотя бы в виде предварительных договоренностей на партнерском форуме.
Zabava_; rendalina; mytg; PAVI; sereginseregin; +5 Ответить
62. Марат Хафизов (Painted) 18 05.07.17 08:38 Сейчас в теме
(11)
Почему тупой управленец, ... нанял вас, дает вам задания и платит вам зарплату?
Это уже философский вопрос - почему в нашей стране так много тупых вороватых управленцев? Требует отдельного исследования. ))
64. Роман Иванов (АльфаАвтоПрограммист) 06.07.17 15:25 Сейчас в теме
(58) Вам прям надо отдельную статью сделать)) Вообще ситуация вполне стандартная для крупных предприятий, но каждый раз эти интриги - как в первый))
У Вас на проектах разделяют политического руководителя и технического?
65. Роман Иванов (АльфаАвтоПрограммист) 06.07.17 15:27 Сейчас в теме
(51) Стали думать о передаче информации в 1С непосредственно со станка, но не нашли спеца.

Подскажите, пожалуйста, модель станка?
66. Ирина Павленко (PAVI) 1648 07.07.17 08:17 Сейчас в теме
(65)
К сожалению, уже не помню. С этим клиентом мы работали несколько лет назад. Но, думаю, тема передачи данных со станков в разные базы 1С актуальна и сейчас. Если у Вас есть какие-то наработки - выкладывайте на Инфостарт, Вас найдут )))
67. Геннадий Николаев (genayo) 07.07.17 15:20 Сейчас в теме
(66) Когда узнают стоимость "получения данных со станков", особенно когда их много и различных производителей, тема быстро перестает быть актуальной...
Оставьте свое сообщение