6 стереотипов при внедрении 1С

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

Здесь я напишу о другом. Я приведу некоторые стереотипы, которые широко распространены на рынке и часто встречаются в компаниях самого разного размера и разных отраслей при реализации проектов. Я понимаю, что есть люди, которые хотят внедрять 1С и не знают, с чего начать. Промониторив рынок, они наверняка столкнулся с этими стереотипами и будут ориентироваться на них.

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

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

1. «Внедрим типовое решение»

Для начала нужно понимать, что такое 1С. Платформа 1С — это среда для разработки. На ней есть готовые решения (конфигурации, разработанные самой «фирмой 1С» — Бухгалтерия, УТ, ЗУП, УПП, ERP и др.; или же ее представителями-франчайзи — например, ИТАН: Управленческий баланс, Бит.Финанс, ИНТАЛЕВ и др.)

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

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

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

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

А многие другие объекты и опции (например, документы для ввода управленческих данных, автоматические «контроли» действий пользователей, некоторые отчеты) намного проще для разработки. Часто такие функции приходится значительно перерабатывать при внедрениях — иногда настолько, что отдельные подсистемы оказываются написанными практически с нуля. Более того, в некоторых случаях написать с нуля менее трудозатратно, чем переработать существующий функционал до нужного состояния.

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

Иногда компании говорят: «Перестроим наши бизнес-процессы под функционал системы».

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

На самом деле тут могут быть разные ситуации:

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

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

Не нужно делать так.

2. «Будем вести все в одной базе»

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

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

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

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

3. «Внедрим с первого раза»

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

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

Если коротко

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

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

Вообще «внедрение» как отдельный проект — очень условное понятие. Существует постоянный процесс использования системы, и она требует постоянного сопровождения и постоянной оптимизации в компании. «Внедрение» — просто условно ограниченный первоначальный пакет таких работ.

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

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

Постоянно обсуждайте с проектным персоналом: есть ли какие-то проблемы? Почему они возникли? Почему их не получится решить? Какие проблемы возникнут при таком-то действии? Как их нужно/нужно было/нужно будет решить?

Как только вы услышите фразу вроде «для того чтобы сейчас это работало нормально, нужно было сразу внедрять чуть-чуть по-другому» — поставьте в список задач исправление этого механизма!

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

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

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

Будьте готовы к затратам на рефакторинг, к затратам своих сотрудников на переговоры с IT-специалистами, на тестирование продукта, к многократному проведению совещаний с закрытыми дверями («пока не опишите требования — не выйдете из кабинета»). Все это стоит дорого. Но другого выхода нет.

4. «Будем искать программиста с опытом в конкретной конфигурации»

Если, кроме программиста, в компании будут аналитики (консультанты, методологи), то на качество работы программиста, по моему опыту, повлияют две вещи:

  1. Уровень знания кода платформы 1С в целом (методы, процедуры и т. д.).
  2. Желание работать качественно и системно.

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

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

5. «Руководителем проекта должен быть программист»

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

  • мог обсуждать с вами и с другими «заказчиками от бизнеса» задачи, вовремя предугадать и объяснить проблему, которая возникнет при реализации того или иного требования;
  • мог предложить и обсудить альтернативные варианты реализации, выбрать оптимальные и объяснить их более низко квалифицированным разработчикам;
  • сам вел разработку самых сложных механизмов.

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

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

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

Кроме того, главный разработчик часто не имеет достаточного представления о предметной области, чтобы вовремя обнаружить риски (заглянув «какие требования заказчик выставит завтра»).

6. «Руководителем проекта будет топ-менеджер»

Противоположная ситуация, поскольку руководитель проекта не должен говорить «я в этом ничего не понимаю», когда к нему приходят с проблемами по мелким техническим или методическим задачам.

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

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

Фото: pixabay.com

Комментарии
IT-менеджер, Мурманск

по своей практике - вся проблема 1с попытки внедрить что-то "серьезное" малыми силами (в том числе и менее затратно)
если еще такие вещи, как бухгалтерия и кадры по отдельности на небольшом предприятии можно запустить используя  3х человек в проекте (так как в этих областях славо богу на предприятиях есть понимание чего они хотят и ждут), то уже даже совмещение Бух+ЗУП уже нарывается на подводные камни при внедрении, а что уже говорить об отпраслевых конфигурация - то еще болото в которое попадает заказчик (и тут уже зависит от франчайзи насколько им интересен заказчик и они готовы ему помочь).... 

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

IT-менеджер, Красноярск

Хорошая статья. Добавлю еще один стереотип: "Нанять программиста 1С в штат дешевле, чем привлечь к работе фирму-Франчайзи".

Системный аналитик, Санкт-Петербург

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

Бизнес к внедрению 1С приходит тогда, когда уже не может "по-старинке", управлять из экселя. Когда от данных захлебываются, и когда их же (данных) не хватает. Когда «серой прозрачности» уже недостаточно. Когда собственнику хочется выйти из операционки. И этот момент, как раз, требует систематизации. И это больно. Это требует перестройки. Это вскрывает пласты злоупотреблений, не эффективности, «кривости».

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

P.S. На внедрение можно смело закладывать мультипликатор Х3 от стоимости решения. Так, например, коробочная SAP стоит 400 000 $, ее внедрение, без "допилок" оценивают в 800 000 $ . 

Консультант по корп. финансам
Сергей Зайков пишет:

по своей практике - вся проблема 1с попытки внедрить что-то "серьезное" малыми силами (в том числе и менее затратно)

Согласен, хотя 1С, наверное, сейчас самая дешевая система - огромная часть проблем возникает именно из-за экономии на внедрении.

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

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

 

Антон Французов пишет:
Хорошая статья. Добавлю еще один стереотип: "Нанять программиста 1С в штат дешевле, чем привлечь к работе фирму-Франчайзи".

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

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

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

 

Антон Врублевский пишет:

Так же все же разделял бы понятия автоматизации и систематизации. Автоматизация, это когда мы считали QR-код и данные с бумаги попали в программу. Т.е. меньше тратится времени человека в рамках процесса. А систематизация – это как раз жесткие рамки, по которым людей вынуждают работать. Конфигурации 1С это, как раз, скорее средства систематизации, нежели автоматизации.

Я стараюсь говорить проще - если стали использовать любую программу вместо работы в тетрадке, это автоматизация

Понятие "систематизация" можно вообще по-разному понимать, оно слишком сложное

И бизнесу сегодня, часто, не хватает именно систематизации. В процессе развития ставятся процессы «хоть как то».

... При этом бизнес упирается, что «программу надо доработать», потому что она не умеет работать «с нашим инновационным ноу-хау».

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

Бизнес к внедрению 1С приходит тогда, когда уже не может "по-старинке", управлять из экселя. Когда от данных захлебываются, и когда их же (данных) не хватает. Когда «серой прозрачности» уже недостаточно. Когда собственнику хочется выйти из операционки. И этот момент, как раз, требует систематизации. И это больно. Это требует перестройки. Это вскрывает пласты злоупотреблений, не эффективности, «кривости».

Согласен! По-хорошему, эксель тоже нельзя строить серо-прозрачно и нужно через какое-то время "рефакторить". Это, в принципе, не проблема 1С или других ERP/учеток или экселя.

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

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

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

Системный аналитик, Санкт-Петербург

Андрей Панахов пишет:
Я стараюсь говорить проще - если стали использовать любую программу вместо работы в тетрадке, это автоматизация Понятие "систематизация" можно вообще по-разному понимать, оно слишком сложное

Подмена понятий приводит к подмене ожиданий. От автоматизации ожидают снижения издержек. Систематизация, на первом этапе, в 100% случаев приведет к росту издержек, т.к. с системой должны взаимодействовать люди, на регулярной основе, и согласно правилам. А это все отнимает время у сотрудников, не создавая добавленной стоимости. На первом этапе это всегда так.

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

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

Андрей Панахов пишет:
Согласен! По-хорошему, эксель тоже нельзя строить серо-прозрачно и нужно через какое-то время "рефакторить". Это, в принципе, не проблема 1С или других ERP/учеток или экселя. Проблема в том, что внедрение 1С или другой ERP/учетки показывает проблемы, которые были раньше, и требует их решить, чтобы закончить внедрение. Но вообще это плохо, это побочный эффект, и по-хорошему его быть не должно, все проблемы должны быть решены вне проекта. Они и так решаются по сути вне проекта, потому что он просто откладывается на время, пока их решат

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

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

А без системы: хочу – пишу, не хочу – не пишу, и если пишу, то когда хочу. Пишу что мне удобно/выгодно.  И главное никто никому предъявить ничего не может, никто ни какой внятной информацией не владеет, но все это как то работает.

 

Системный аналитик, Санкт-Петербург

Есть МСФО - Мировой Стандарт Финансовой Отчетности. Тоже система, соблюдая которую мы смотрим на стандартные метрики. На них смотрят другие. Мы понимаем сколько мы стоим. Можем +/- по этой цене продать бизнес или привлечь инвестиции. Т.е. это же возможно?Никто же не говорит, что это легко. Или не трудозатратно. А у нас.. Покажите мне бизнесменов которые не плюются при словах "Баланс", "ДДС"?

Консультант по корп. финансам
Антон Врублевский пишет:
Без автоматизации, оператор пишет в журнал, а в конце смены мастер забирает журнал и вводит это все ручками в 1С. Но все это в рамках системы.

Всё очень просто: Вы путаете автоматизацию производства с автоматизацией учета, а еще точнее - с "автоматизацией хранения данных", которую выполняет любая база данных.

А еще 1С выполняет автоматизацию обработки данных (например, группировки данных для вывода в отчеты).

Директор по развитию, Москва

Как быстро пролетело время. Уже на программу 1С учебники пишут, диссертации защищают. Рабочие специальности вводят. Спорят, кто должен за 1С отвечать.

А начиналось с одного замечательного маркетолога. Ему было вообще все равно, что это за программа. Он настоял бесплатно установить ее в минфине и казначействе. Теперь всем на нее молиться. Ведь были же более удобные и "легкие" программы учета, монетизации и автоматизации. Они и сейчас есть, но их задушил монстр 1С.

Аналогично была внедрена одна СПС

Консультант по корп. финансам
Александр Воротовов пишет:

Как быстро пролетело время. Уже на программу 1С учебники пишут, диссертации защищают. Рабочие специальности вводят. Спорят, кто должен за 1С отвечать.

А начиналось с одного замечательного маркетолога. Ему было вообще все равно, что это за программа. Он настоял бесплатно установить ее в минфине и казначействе. Теперь всем на нее молиться. Ведь были же более удобные и "легкие" программы учета, монетизации и автоматизации. Они и сейчас есть, но их задушил монстр 1С.

Аналогично была внедрена одна СПС

Возможно, во всем ПО так.

А в бизнес-автоматизации (учет, ERP и пр.) тем более. Принцип практически один во всех платформах. Поэтому кто займет рынок - это вопрос чего-то типа стихии/случайности/маркетинга.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
ИИ спрогнозирует увольнение

«Сбербанк» начал оценивать соискателей при найме консультантов с помощью ИИ.

Безработица-2020 останется прежней

Министерство труда и социальной защиты России спрогнозировало стабильность.

Как управлять коллективом?

В Ижевске состоялась конференция «Региональная модель управления человеческими ресурсами».

Кто хочет знать зарплату коллег

Служба Исследований hh.ru выяснила, кто из соискателей знает размер зарплаты своих коллег.