Зачем нужен 1С-аудит?

Цель статьи: рассказать о продукте, который хотел бы запустить.

Аудитория - потенциальные партнёры:

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

Мой продукт - аудит проектов, баз, сопровождения.

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

👉Неавтоматизация действий исполнителя

Важно! Сейчас идёт рекламная кампания всемогущего искусственного интеллекта. Доля ИИ в инструментарии проекта скорее всего, должна быть, но на сегодня она не только не самая важная, но и не всегда существенная. А вот без других инструментов трудозатраты могут возрасти критически. Значение каждого инструмента зависит от многих факторов. Например, при работе с Гит важно наличие конвейеров, выполняющих часть действий за разработчика. Считаем: пусть работа с Гит занимает 5% времени разработчика, конвейеры отсутствие конвейеров приведёт к удвоению этого объёма. Разработчиков по стоимости оплаты труда примерно 50% в проекте, а оплата труда 80% от затрат проекта. Итого получаем 2% стоимости 'разработки проекта, что немало для одного показателя

👉Отсутствие работы с рисками

На некоторых проектах работы с рисками просто нет. Она ведётся эпизодически и на уровне "если мы эту задачу не выполним, то завтра не придут деньги, а послезавтра не будет зарплаты". Как ни странно, даже с таким подходом проекты вполне неплохо могут завершиться. Но ключевое слово "могут". Считаем: пусть каждая сотая задача может возрасти в цене вследствие рисков в 5 раз. С вероятностью 50% при надлежащей работе с рисками этих затрат можно избежать. Пусть все задачи равны по стоимости, тогда получаем 2%. Здесь моя оценка - лютый волюнтаризм, но такова оценка рисков - не так уж часто их возможно оценить на базе опыта.

👉Налог на прибыль

Несколько раз видел доработку филиалов для учёта прибыли и НДФЛ. Это пример "лишней" доработки, которая повышает стоимость владения. Считаем: пусть раз в год обновления затрагивают эту доработку и приводят к 8 часам лишней работы программиста. Ежегодно 40+ тысяч ненужных затрат.

👉Нет стандарта разработки в большой команде.

Иногда "продвинутые" заказчики выдвигают требования к разработке. Каким образом? ИИ или гугл помогают составить такой список. Заказчики берут этот большой список целиком.

Исполнитель возражает? - Конечно, это же не в его интересах, не режем ничего.

Чем плох такой подход? Выполнение любых требований стоит денег. Нередко в список попадают чрезмерные требования, и Заказчик платит за исправления несущественных ошибок. Оценим возможный масштаб: Если даже разработчик потратит на эти работы 1% времени - это около 0,5 % от стоимости разработки проекта. Вносятся изменения в типовую часть.

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

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

👉Требования заведомо лишних доработок – встречается часто. Такие требования могут возникать по разным причинам. Но тоже могут существенно нарастить стоимость проекта. У меня были проекты, когда заказчик отказывался от четверти задач по объёму, а раз смог отказаться – значит, доработки были несущественными, либо вообще лишними.

👉Непродуманные процессы проекта. Примером последствий может служить «Антидедлок» - каждый из участников процесса считает, что задача у партнёра, а выполнение останавливается. С учётом влияния на другие процессы – тоже может вызвать существенные затраты.

👉Даже на действительно лучших проектах есть дорогостоящие неточности. Технологии обновляются, жизнь меняется, даже лучшие не могут уследить за всеми новшествами. Аудит – то второе мнение, которое поможет сберечь деньги.

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

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

❓Есть ли «план Б»? Да, кроме проектов можно оценивать и сопровождение.

❓Кому аудит интересен?

Возникает странная ситуация:

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

❓Выгодно ли такое направление для аудиторской фирмы? Интуитивно – да, заказчики будут. Но я не маркетолог, и считаю, что надо спрашивать специалистов. Я могу дать вводные по затратам.

❓Что надо сделать для старта? Дел будет много: формирование команды, чеклисты проверок, инструменты, методики…

Заинтересовались темой? Давайте попробуем продвинуть. Это не быстро и не просто, но кто ж обещал, что будет легко?