Хроники хаотичного ведения учета и как не стоит внедрять проекты

Описан опыт работы в одной производственно-торговой компании и внедрения конфигурации КА 2 (комплексная автоматизация). Также что из этого получилось и какой урок был получен.

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

Параллельно у других программистов (нас было 3) шли другие проекты по мобильной системе, документообороту и т.д. Походу проявлялись недочеты текущих систем и по возможности исправлялись. Торговая база была автоматизирована на БП 2. Примерно через месяц так и не получив ответов на 80% вопросов я составил черновой вариант технического задания. Вопросы, по моему мнению, были простыми:

  1. учетная политика
  2. управленческая структура компании
  3. список бизнес-единиц, сфера деятельности, схема обменов данными
  4. правила по скидкам, акциям, контроль дебиторки
  5. и т.д.

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

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

Для начала автоматизации выбрал сперва 3 российских филиала на основе УТ 11. Доработал конфу, доработал шину данных для автоматизации мобильной системы. Развернул тестовую среду, каждому объяснил, как работать, написал инструкции, схемы процессов. Реакция у 2 филиалов почти нулевая. Один филиал тестировал, но вяло. Несколько раз обращался к коммерческому директору, чтобы он, так сказать, "приказал" работать по выстроенной схеме. Исполнительность нулевая. Писал всем и говорил, короче помощи никакой. Проект был наполовину провален. Удалось лишь централизовать базу и перенастроить мобильную систему у одного филиала, остальные забивали документы вручную. Сообщил об этом руководству. Реакция нулевая. Была нулевая, пока не узнали, что не внедрена новая мобильная система (было 2, старая и новая, разработанная в компании). Меня штрафанули на 10% зарплаты. Я начал спрашивать, на каком основании, сказали, что из-за мобильной системы. Начал доказывать, что даже их непосредственный руководитель в лице коммерческого директора не смог повлиять на них, чтобы они протестировали новую систему и т.д. Короче я крайний, доказать не удалось несмотря на все доводы.

В качестве конфигурации для автоматизации филиалов Казахстана была выбрана "Комплексная автоматизация для Казахстана, ред. 2". Тут мне директор говорит, что конфигурация должна быть типовой. ОК. В принципе можно. Хотя в ТЗ, которое так и не подписали, было четко написано, что конфигурация будет доработана.

Назначили из финансового департамента основного ответственного за общение с конечными пользователями. Т.е. сперва показываю, объясняю им, а дальше уже конечным пользователям. Так как филиалов и пользователей немало (14 РП, свыше 100 юзеров), а программистов мало, договорились, что они будут первой линией консультации. Составил поэтапный план внедрения. Времени было мало, оставалось полтора месяца. Нужно было запустить с начала нового года. Месяц был потерян из-за неисполнительности первых 3 РП. Выбрали один РП. Начали тестировать, устранил ошибки. Шел по плану внедрения с чеклистами по областям. Каждый день обновлял статус проекта и отписывал руководству.

Столкнулись с со следующими проблемами:

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

2. Низкий уровень IT-инфраструктуры. Вообще в компании был режим суперэкономии. Сисадмины уже больше года не могли добиться нового сервера. Нестабильный интернет.

3. Неисполнительность. Как ни парадоксально, руководство головного офиса по факту не могло повлиять на пользователей. Элементарно не читали инструкции, письма. Решили не платить зарплату тем, кто не будет выполнять задачи по проекту внедрения. Вроде зашевелились, кроме одного основного региона. Об этом позже.

4. Неудобность работы в новых условиях. В компании не было понятия резервов товаров. Хотя ей уже больше 10 лет. В инструкциях по полстраницы описывал теорию и практику на максимально простом языке, что такое резерв товаров, разницу между доступным остатком от того, что в наличии и т.д. Контроль минусовых остатков товаров был, но по факту не работал. Некоторые механизмы, которые якобы работали в старой базе, по факту не работали. Операторы подгоняли вручную.

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

В принципе, масса проблем была решена. Но операторы основного региона не тестировали. Раза 3 говорил своему "связному" (ответственный от финдепа). Связной пригрозил зарплатой еще раз. Реакция, так сказать, не очень. Вообще у этого региона ввиду большого оборота и отсутствия понятия контроля минусового остатка товаров были постоянные серьезные проблемы с инвентаризацией. А для начала тестирования они должны были сделать инвентаризацию. Сделали, ждали результатов инвентаризации в базе неделю.
Возникает серьезная проблема. Примерно за 10 дней запуска связной срочно уезжает.  Говорит, на 2 недели. А как же проект? Обещает быть на связи. ОК. 2 недели потерпим.
В целом картина перспективная 12 филиалов запущены, 1 проблемный, но запущен, 1 на потом на февраль (операторы в отпуске почти весь январь).
До нового года неделя. Решили запускаться. Чеклист велся.Запустились. Запускались поэтапно. Каждые 2 дня по 2 филиала. Действия дублировались и в новой и в старой базе, так как не сезон. Обороты маленькие в силу специфики сферы деятельности.

Первыми запускались 1 основной и 1 маленький филиалы. Первым 1 проблемный и 1 маленький. В силу того, что проблемный нормально не тестировался, им пришлось тяжко. Не читали инструкций. Пришлось работать в 12-часовом режиме. В субботу тоже и в воскресенье по полдня удаленно. Финдеп, который должен был быть первой линией консультации, по факту не исполнял свои обязанности ввиду отсутствия "связного". Как бы он был на связи, но все равно физическое присутствие на рабочем месте в крупнейшем проекте компании это другое.

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

После напряженного режима в течение 2-х месяцев я заболел. Отсутствовал на работе 4 дня. После прихода проблемный филиал до сих пор не мог привыкнуть к контролю минусовых остатков товаров. Реализации, перемещения не проводились. Соответственно страдала отгрузка товаров клиентам. Также была проблема с оверстоками на бортах. Т.е. погружаемый товар просто не вмещался в машину, которая довозила товар клиенту. Алгоритм был таков: если товар есть на борту, то его не надо грузить еще. Также было округление до коробки определенного списка товаров. Я начал проверять код обработки, обнаружил ошибку, исправил.

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

Я начал анализировать, написал отчет по остаткам, реализациям и предоставил доказательства, что не виноват. Бесполезно. Подозревали меня даже в диверсанстве, что я специально это сделал и специально заболел на 4 дня. Но непонятно для чего. В компании в целом отсутствовало понятие оперативности. Например, поступил товар на склад, могли тупо не оформить поступление и дальше продавать, так как контроля минусовых остатков не было. Потом когда обнаруживали, что документ не оформлен в базе, оформляли задним числом. Происходила непонятная котовася или котопес. Короче полная жесть.

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

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

2. невозможность выстроения единой логики работы. Каждый филиал работает по своей какой-то схеме. Финдеп не в курсе, как контролируется дебиторка, рассчитывается себестоимость товара, не знают, что такое учетная политика. И "света в конце туннеля" не было видно.

3. система штрафов. Не доказав до конца, штрафуют даже если ответственные лица за тестирование не выполняли свои обязанности. Т.е. по любому виноват программист. Также не выполнялись даже прямые приказы, подписанные президентом компании.

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

5. отсутствие фильтра при ведении разработок/доработок. Владельцем всех ИС был финансовый директор. Через него шло согласование доступа, доработки, разработки и т.д. И вот когда какой-то сотрудник предлагает доработать что-то, я отправляю к нему. Он всегда согласовывает. Даже если там нет детализации что и как. За 11 месяцев работы не было ни одного отказа. Тогда вопрос: зачем вообще нужно согласование от финдира?

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

В итоге для себя я сделал следующие выводы:

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

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

3. не бояться проваливать проекты. После определения ответственных за тестирование, предоставление информации, задач со стороны заказчика регламентно ведите чек лист, контролируйте исполнение. При неисполнении эскалируйте на его руководство и т.д. до самого верха, если надо до первого руководителя. Этот важный момент с первым руководителем, я к сожалению, пропустил. Возможно, если бы он узнал, что реакция со стороны пользователей вялая, подействовал бы на них. Если протестировано мало участков системы (менее 50%), при сильном отставании от графика смело засчитывайте проект проваленным. Сообщите всем. Письмами, звонками, СМС-ками, через Telegram, WhatsUp, Skype и т.д.

4. доверяй, но проверяй. Документируйте все этапы проекта. Не прям все до точки. В проекте должны быть определенные вехи. Подписывайте у руководителей ТЗ, план проекта. Если не подписывают, можете подыскивать другую работу. Не действуйте как в моем случае, если вам не подпишут ТЗ и скажут начать проект, не соглашайтесь. Через полгода, когда руководители спросят у вас, почему не реализован тот или иной механизм, покажете подписанное ТЗ.

5. удостоверяться, что условия работы подходят. Чай, кофе, чистый воздух, климат в кабинете, железо — все это вроде бы мелочи, но начинают напрямую влиять на производительность, если какое-то звено хромает. Работа программиста больше творческая нежели техническая. Еще со школьных времен мне говорили учителя что люди, связанные с умственной работой, тратят больше энергии, нежели связанные с физической.

6. не заниматься неблагодарной работой, не перерабатывать просто так. Все должно компенсироваться и оплачиваться, и надо здесь и сейчас. Никаких потом. Если говорят, мы тебя повысим через 2 месяца, требуйте документ (приказ, предложение о повышении и т.д.). Оговаривайте сразу, что переработки будут оплачиваться в соответствии с трудовым законодательством. Вы, наверное, подумаете, что я страдаю манией величия, но это не так.

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

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

31 Comments

  1. tailer2

    ну, да

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

    Reply
  2. Maxisussr

    (0)

    Автор, долго тянул с уходом…

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

    Reply
  3. genayo

    Все по классике, все грабли собрал… Ладно хоть уволился, геройствовать не стал…

    Reply
  4. KAV2

    12 внедренных филиалов это большой успех, совсем не провал.

    Reply
  5. spezc

    Мужик! Такое выдержал. Теперь закален на всю жизнь)))

    Reply
  6. kauksi

    Отрицательный результат — тоже результат. Главное — не побеждать, а участвовать -олимпийский принцип ))

    Reply
  7. CtepaN

    Автору не приходило в голову одно простое предположение: Возможность постановки грузов(товаров) на учет «задними» датами, ручная правка остатков, текучка кадров и работники на низких зарплатах — это возможность «левачить».

    При таких раскладах точный учет не нужен никому. Бился автор в несколько глухих стен…

    При этом умудрился получить положительные результаты. Молодец.

    Reply
  8. Olga_aku

    Статья понравилась. Но тоже подумала, что в учёте там не нуждались. Игры в автоматизацию.

    Автор молодец.Выводы что надо. И сам марку держал.

    Reply
  9. grimih

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

    Опыт — это совершенно бесполезные знания о том как не надо было поступать в прошлом. Теперь предстоит самое интересное — конвертировать свои синяки и шишки в звонкую монету. Успехов!

    Reply
  10. baracuda

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

    Постараюсь извлечь уроки.

    Reply
  11. Droonimus

    С течением времени стал серьезно относиться к уставу проекта. Жаль, что сейчас ими (проектами) не занимаюсь, так бы там всё расписывал, вплоть до размера штрафов. Лично мне видится тут отсутствие команды со второй стороны — есть кому писать и внедрять, но нет ответственной группы со стороны заказчика. Такая затея изначально обречена на провал. Это происходит ровно тогда, когда начинаешь что — то требовать с пользователей. В случае классического подхода, надо требовать с того, кто прописан в уставе или договоре — то есть с конкретного ответственного лица. Накатал ему телегу на саботирующих процесс и на очередной рабочей группе попросил предоставить решение сложившейся проблемы. Если что — тыкать в устав! Это как конституция, истины которой непреложны! 🙂

    Reply
  12. Разумов

    Спасибо за статью. Но выводы мне показались странными.

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

    — доверяй, но проверяй;

    — удостоверяться, что условия работы подходят;

    — удаленность от дома;

    — не заниматься неблагодарной работой, не перерабатывать просто так.

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

    Вывод такой: если это никому не нужно, то этого и не будет.

    А вопрос такой: какого хрена я оставался в этой яме так долго? Зачем? Почему? Я что, сразу не понял, что условия работы мешают труду? И что везде хаос и неразмериха? И что плохо то, что критические важные документы никто не читает и не подписывает? Это было ясно с самого начала. Ну так что же меня держало в этой яме?

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

    Тут я, может, упрощаю ситуацию, но так вижу по статье.

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

    Так, я на первой работе был очень угнетён разными причинами, и тоже пытался оправдать как можно обстоятельно перед собой и другими свои провалы, даже если они произошли не по моей вине. По когда меня, после всех нервотрёпок с проектами, в которых тоже никому ничего не было нужно, штрафанули за опоздание на 140 рублей (на сто сорок рублей, Карл), я психанул и написал заявление. Не советовался ни с коллегами, ни с женой, на собеседования не ходил — просто ушёл. И это был очень правильный шаг: на второй работе, которая нашлась сразу же, у меня открылось второе дыхание, и всё стало прекрасно.

    Reply
  13. Alex_Japanese_Student

    Бывают проекты где невозможно внедриться, каждый когда-то через них проходит, увы

    Reply
  14. AlexeyT1978

    Похожий проект, но боссы на порядок лучше.

    Reply
  15. madonov

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

    Никто из них не был заинтересован в нормальной организации учета. Чем меньше порядка — тем проще филиалу обуть голову.

    Отсюда и «серьезные проблемы с инвентаризацией» и саботаж проекта по внедрению новой системы учета.

    Reply
  16. DimDiemon

    Начинать надо было с целей автоматизации, договариваться о поддержке с собственником, а не с топами…

    Грабли знакомые, бьют больно…

    Reply
  17. zawal

    Невозможно автоматизировать бардак.

    При автоматизации получается, бардак автоматизированный!

    Опыт., очень важный опыт получен.

    «Ты сильный, ты справишься!

    Нет, я умный, я даже не возьмусь!»

    Reply
  18. Stim213

    Автор взял на себя ответственность за весь учет — и это неправильно.

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

    Руководителям нужна прибыль прежде всего. Автоматизация сама по себе хороша, но когда вы говорите, что при внедрении п.1 -п.10 вашего проекта прибыль увеличится в 2 раза — тут уже руководители начинают пинать филиалы и подгонять под ваши сроки

    Reply
  19. ifilll

    (5) Это только начало.

    Reply
  20. ifilll

    (7) Верно, всегда найдутся сообразительные товарищи кто повернет себе во благо ))

    Reply
  21. ifilll

    Классика, автор придумал что ответственный за все, а боссы как обычно не знают что делают и не знают зачем, пока баланс положительный ))

    Reply
  22. DmitryKSL

    «в компании был режим суперэкономии»

    «на руководящих должностях 70% были родственники или родственники родственников»

    надо же так вляпаться…

    Reply
  23. DDA4746

    (6) Дада, в гонке на выживание главное — участие 🙂

    Reply
  24. DDA4746

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

    Потому что там, где все хорошо, автоматизаторы особо не нужны — в лучшем случае нужно сопровождение.

    Автору удачи в поисках исключений из правила 🙂

    Reply
  25. uri1978
    Примерно за 10 дней запуска связной срочно уезжает. Говорит, на 2 недели. А как же проект? Обещает быть на связи.

    — как это знакомо.

    Reply
  26. MaxDavid
    2. нужно иметь при себе несколько контрольных вопросов в сторону потенциального работодателя при прохождении собеседования.

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

    Reply
  27. firma111

    Опыт, конечно, любопытный. Но изначально понятно, что если «программист 1С» берет на себе одновременно обязанности РП, аналитика, архитектора на таком крупном проекте, из этого ничего путного не выйдет. Даже если руководство адекватное, условия труда хорошие и т.п. Не способен никакой специалист, если это конечно не гений какой-нибудь, охватить такой огромный круг вопросов, за все отвечать, все тащить на своем горбе. Максимум, что можно вменить в ответственность программиста 1С, помимо написания кода, это написание ТЗ (на основе разработанных другими людьми БП), да и то далеко не везде ТЗ пишут программисты, для этого есть отдельные люди — аналитики, архитекторы. В нормальных конторах по крайней мере это так. Так что описанная ситуация изначально попахивала авантюрой. И с учетом всего этого достигнутые ТС результаты на проекте действительно можно считать отличным результатом.

    Reply
  28. Bajo

    (12)

    просто

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

    Также есть специфика по зарплате, которую к сожалению озвучить не могу. Т.е. уйти просто так невозможно (только сейчас получил окончательный расчет).

    На данный момент все работают и автоматизированы так сказать по-моим схемам . Людей для дальнейшего развития не осталось. После моего ухода решили расширить штат до 6 программистов, т.е. в 2 раза. Вместе с мной с разницей в несколько рабочих дней уволился второй программист. Взяли двух. Один убежал на второй день. Оставшийся прогер в состоянии сильных сомнений.

    Reply
  29. d.zhukov

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

    Reply
  30. oldcopy

    Как все знакомо, за 15 лет работы в аутсорсинге насмотрелись на всякое. Бардак и низкая квалификация сотрудников, в т.ч. ключевых, это реалии отечественного бизнеса, а если они еще и родственники, то объемы бардака возрастают на порядок.

    Но есть одно НО! Отношение к ситуации собственников и их политическая воля. Если есть желание и сила воли наводить порядок — дело пойдет, нет — тушите свет.

    Пару лет назад мы автоматизировали два объекта общепита. На одном собственник фактически самоустранился, мол «я вам деньги плачу, вот и работайте, а мне мозги не сношайте». При этом мы прекрасно видели, что фактическое построение бизнес процессов отличается от описанных в ТЗ, а ответственные сотрудники вместо участия в проекте отмахиваются от нас, как от надоедливых насекомых.

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

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

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

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

    Reply
  31. CheBurator

    В гораздо более меньших масштабах — но знакомо.

    Выводы правильные.

    Линять надо было при первом штрафе.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *