Сейчас я наблюдаю очень много внедрений 1С. Практически постоянно при внедрениях возникают одни и те же проблемы. Я не хочу здесь подробно описывать причины, потому что они известны практически всем, кто хоть как-то сталкивался с этой сферой. Эти проблемы часто решаются, но иногда с большими затратами или с неудачными компромиссами, а иногда не решаются вообще.
Здесь я напишу о другом. Я приведу некоторые стереотипы, которые широко распространены на рынке и часто встречаются в компаниях самого разного размера и разных отраслей при реализации проектов. Я понимаю, что есть люди, которые хотят внедрять 1С и не знают, с чего начать. Промониторив рынок, они наверняка столкнулся с этими стереотипами и будут ориентироваться на них.
Эти стереотипы нельзя назвать однозначными ошибками. Но, сталкиваясь с внедрениями на практике, я понимаю, что применение этих стереотипов не всегда помогает успешно автоматизировать бизнес. Я постараюсь описать некоторые из них и изложить свою точку зрения.
Примечание: статья не относится к автоматизации регламентированного бухгалтерского учета. То, что здесь будет написано, относится к автоматизации управленческих функций учета, документирования и анализа.
1. «Внедрим типовое решение»
Для начала нужно понимать, что такое 1С. Платформа 1С — это среда для разработки. На ней есть готовые решения (конфигурации, разработанные самой «фирмой 1С» — Бухгалтерия, УТ, ЗУП, УПП, ERP и др.; или же ее представителями-франчайзи — например, ИТАН: Управленческий баланс, Бит.Финанс, ИНТАЛЕВ и др.)
Каждая конфигурация представляет набор разработанных объектов, которые иногда тесно связаны между собой, а иногда вообще нет. Разные объекты обычно имеют разную сложность разработки, и часто даже для одной конфигурации их разрабатывают разные люди (если не разные команды).
Предположение, что своими силами нельзя вести разработку на высоком уровне — заблуждение.
Например, механизм расчета себестоимости в типовой 1С: Бухгалтерия — действительно очень сложен (и, кстати, очень качественно реализован), его разрабатывали с использованием фундаментального математического аппарата. Выполнить разработку такого уровня в компании своими силами крайне сложно.
Именно такие сложные модули — и есть ключевая ценность типовых программ, которая делает их покупку выгодной. К ним можно отнести, например механизм согласования документов и отчетов; универсальные конструкторы отчетов; модули обмена и пр.
А многие другие объекты и опции (например, документы для ввода управленческих данных, автоматические «контроли» действий пользователей, некоторые отчеты) намного проще для разработки. Часто такие функции приходится значительно перерабатывать при внедрениях — иногда настолько, что отдельные подсистемы оказываются написанными практически с нуля. Более того, в некоторых случаях написать с нуля менее трудозатратно, чем переработать существующий функционал до нужного состояния.
Поскольку довольно сложно угадать, какие именно модули наиболее сложны для реализации (не будучи специалистом по продуктам 1С), лучший выход из ситуации — составить детальное описание процессов, которые должны быть автоматизированы, и затем получать консультации по выбору продукта. Как правило, сами компании-франчайзи 1С оказывают такие консультации бесплатно. Кроме того, можно обращаться к коллегам/знакомым/сотрудникам.
Иногда компании говорят: «Перестроим наши бизнес-процессы под функционал системы».
Часто этот стереотип связан со стереотипом, будто IT-продукты разрабатываются по передовой методологии, и компания собирается «дорастать» до нее, перестраивая свои рабочие процессы по ходу внедрения.
На самом деле тут могут быть разные ситуации:
- Если рабочие процессы в вашей компании совсем не поставлены (spoiler: бардак), то программа «заставит» соблюдать определенный порядок, она просто навяжет его вам. Причем это наверняка произойдет само собой, когда вы попытаетесь выполнить в программе какое-то действие.
- Но часто рабочие процессы в вашей компании более продвинуты, чем предусмотренные типовой программой. Работая с «топовыми» продуктами и слушая разработчиков софта, можно услышать, что очень много функционала и опций в программах просто не реализовано. Это может быть связано с тем, что процесс разработки сам по себе — долгий, и к сегодняшнему дню что-то просто не успели предусмотреть, и с тем, что рабочие процессы в современных компаниях иногда очень сильно различаются, поэтому нельзя разработать универсальное решение.
Если вы будете адаптировать свои рабочие процессы под программу, которая методологически от них отстает — вы заставите свою компанию деградировать.
Не нужно делать так.
2. «Будем вести все в одной базе»
Существует стереотип, будто на рынке существует один конкретный продукт, который в наибольшей мере подходит под потребности компании.
Это работает при выборе продуктов промышленного производства, но не при автоматизации бизнеса. Потому что структура IT-системы должна в деталях повторять модель самого бизнеса, а бизнес почти всегда — разный.
На практике вы не автоматизируете какие-то общие бизнес-процессы, а автоматизируете конкретную ситуацию. И может оказаться так, что эта ситуация состоит из двух участков, для которых существуют разные специализированные продукты — и их сочетание будет лучше, чем выбор одного продукта, который позволит автоматизировать «везде по чуть-чуть».
Все это следы одного подхода. Нужно не внедрять программы, а строить систему автоматизации в своем предприятии, подбирать разные продукты, которые в сочетании дадут единую систему автоматизации.
3. «Внедрим с первого раза»
Консультанты могут сами не знать реальный бюджет или не озвучивать его потому, что заказчик не готов его услышать.
Есть часть затрат, которая практически никогда не закладывается в бюджет и обычно приводит к большим негативным последствиям — это разбор базовых механизмов и оптимизация уже внедренного функционала (в том числе, так называемый «рефакторинг» — то есть, переписывание кода на более удобный).
Если коротко
- Практически любую обнаруженную недоработку выгоднее исправить сразу, чем отложить. Вне зависимости от того, укладывается она в первоначальный бюджет (планы, сроки) или нет.
- В целом нужно тратить время на то, чтобы разобраться в технической архитектуре системы.
Даже если программисты работали с таким же продуктом год назад, часто есть смысл дать техническому архитектору несколько десятков часов на то, чтобы разобраться в свежей версии.
Вообще «внедрение» как отдельный проект — очень условное понятие. Существует постоянный процесс использования системы, и она требует постоянного сопровождения и постоянной оптимизации в компании. «Внедрение» — просто условно ограниченный первоначальный пакет таких работ.
Не всегда следовать плану проекта — это хорошо. Часто попытки успеть все сдать в срок создают то, что называется «технический долг» (в самом плохом случае это переводится на русский как «внедрить и убежать»; в лучшем случае — означает необходимость исправить на более поздних этапах проекта).
Нужно понимать, что даже очень хорошие разработчики в среднестатистической компании с первого раза наверняка не сделают всю работу идеально. Потому что, во-первых, полностью понять все требования сразу обычно невозможно (даже если они детально прописаны и даже при большом опыте в данной сфере), во-вторых, требования часто меняются уже по ходу проекта, в-третьих, люди не идеальны.
Постоянно обсуждайте с проектным персоналом: есть ли какие-то проблемы? Почему они возникли? Почему их не получится решить? Какие проблемы возникнут при таком-то действии? Как их нужно/нужно было/нужно будет решить?
Как только вы услышите фразу вроде «для того чтобы сейчас это работало нормально, нужно было сразу внедрять чуть-чуть по-другому» — поставьте в список задач исправление этого механизма!
Постарайтесь поверить, что во многих случаях вам выгоднее не оказывать излишнее давление на сотрудников, а принять такой риск как неизбежный и быть готовым к нему.
Если это какой-то фундаментальный механизм, и он был написан на скорую руку (такое бывает, когда на начальных этапах проекта еще не было ясно, насколько он будет значим) / не дописан / устарел, то все дальнейшие наработки сверху на нем наверняка превратятся в «костыли», которые развалятся если не к концу проекта, то после него, или когда ваши сотрудники уже уволятся. И такая экономия вряд ли обойдется вам дешево.
Автоматизация стоит дорого. Часто слишком поздно становится понятно, что некоторые функции, которые уже были куплены и/или разработаны, не соответствуют потребностям компании и их нужно переработать, значительно расширив бюджет и сроки проекта. Из этой ситуации нет однозначного выхода, но, если автоматизация началась, можно порекомендовать расширить бюджет для доведения начатых участков до рабочего состояния. Иначе — неиспользуемый софт («у нас стоит 1С-ка, но мы все равно ушли в Excel/в электронную почту»), неудобный недоработанный софт, который лучше бы не использовался («раньше так быстро все было, а теперь стало только хуже и дольше»), дикие трудозатраты персонала на внедрение (бесконечное тестирование, «параллельная работа в двух системах», «кто виноват») и другие провальные результаты проекта.
Будьте готовы к затратам на рефакторинг, к затратам своих сотрудников на переговоры с IT-специалистами, на тестирование продукта, к многократному проведению совещаний с закрытыми дверями («пока не опишите требования — не выйдете из кабинета»). Все это стоит дорого. Но другого выхода нет.
4. «Будем искать программиста с опытом в конкретной конфигурации»
Если, кроме программиста, в компании будут аналитики (консультанты, методологи), то на качество работы программиста, по моему опыту, повлияют две вещи:
- Уровень знания кода платформы 1С в целом (методы, процедуры и т. д.).
- Желание работать качественно и системно.
На первое влияет только опыт, причем не в годах стажа, не опыт в конкретных конфигурациях/ в автоматизации конкретных сфер бизнеса, а опыт решения конкретных технических вопросов, и без технического собеседования вы вряд ли это оцените. Второе — это уже общее качество человека, и оценить его еще сложнее, практически невозможно, пока не поработаешь с ним.
Если в компании нет аналитика и его функции ложатся на программиста — с одной стороны, сертификаты и опыт могут немного помочь ему. С другой стороны, важность второго пункта при этом становится настолько критичной, что перекрывает возможную пользу от сертификатов. Поэтому проблема подбора подходящего программиста остается в любом случае, и способ решить ее я пока не сформулировал.
5. «Руководителем проекта должен быть программист»
В команде должен быть один (хотя бы один) квалифицированный разработчик, которому вы доверяете. Принципиально не важно, кем он будет — программистом, архитектором или руководителем проекта. Важно, чтобы он делал две три основные вещи:
- мог обсуждать с вами и с другими «заказчиками от бизнеса» задачи, вовремя предугадать и объяснить проблему, которая возникнет при реализации того или иного требования;
- мог предложить и обсудить альтернативные варианты реализации, выбрать оптимальные и объяснить их более низко квалифицированным разработчикам;
- сам вел разработку самых сложных механизмов.
Если он захочет вас «кинуть» — он сможет сделать это на любой должности. Что касается какого-то координатора проекта, он тоже должен быть (часто именно для этих функций и назначается руководитель проекта) и он должен:
- понимать общую картину проекта (что нужно сделать, для кого и для чего нужно сделать, в какой последовательности, кто за что отвечает, кто чем занят сейчас), т. е. централизовать всю информацию, которая влияет на состав задач / сроки работ / стоимость работ, и владеть ею на любой момент;
- распределять задачи, контролировать сроки работ;
- вовремя мониторить случаи, которые повлияют на задержку/удорожание проекта/потерю смысла в нем и другие срывы планов.
Если этот человек и главный программист разные люди — я считаю такую ситуацию абсолютно нормальной. И зачастую она даже лучше, поскольку навыки распределения задач и другие менеджерские качества у высококвалифицированных разработчиков не всегда хорошо развиты.
Кроме того, главный разработчик часто не имеет достаточного представления о предметной области, чтобы вовремя обнаружить риски (заглянув «какие требования заказчик выставит завтра»).
6. «Руководителем проекта будет топ-менеджер»
Противоположная ситуация, поскольку руководитель проекта не должен говорить «я в этом ничего не понимаю», когда к нему приходят с проблемами по мелким техническим или методическим задачам.
Топ-менеджеры «от бизнеса» очень часто хотят или вынуждены говорить именно так — из-за того, что они очень заняты, или из-за того, что им не хватает каких-то знаний (например, если человек не понимает на базовом уровне, как устроена структура базы данных). Они часто выступают кураторами проекта, однако при их назначении руководителями проектов не могут выполнить всех необходимых функций — например, разбить крупные задачи на более мелкие, распределить их между исполнителями, принять нестандартное творческое решение на стыке «IT» и «бизнеса».
В таких случаях между «бизнесом» и «IT» возникает провал, который или вообще не заполняется (руководитель проекта консолидирует информацию «от бизнеса», но не может соединить ее с информацией от технического руководителя), или заполняется специалистами, у которых нет полномочий распределять задачи и менять состав работ (бизнес-аналитиками и другими).
Фото: pixabay.com