Комментарии0
Что за проект
Клиент обратился с задачей перенести базу «Зарплата и управление персоналом» (ЗУП) со второй редакции на третью. Причем база была не типовой — с рядом доработок, включая нестандартные схемы расчета больничных и модификации справочников. Параллельно требовалась настройка синхронизации с Бухгалтерией. Мы дали положительный ответ: задача показалась нам интересной, объемной и вполне посильной.
Почему взялись за проект
На тот момент у нас уже был опыт переноса доработанных баз, включая сложные конфигурации вроде Бухгалтерии с весовыми, мельницами и другими специфическими блоками. Эти проекты удавалось выполнять качественно и в одиночку. Поэтому мы предположили, что с доработанным ЗУП можно справиться аналогичным образом. Увы, это оказалось ошибочным допущением: специфика ЗУП существенно отличается от других конфигураций и требует более глубокого понимания предметной области — расчета зарплаты, взаимодействия с учетом и синхронизации.
Что пошло не так
Главная проблема оказалась в том, что мы сильно недооценили объем и сложность ручной работы при переносе доработанного ЗУП. Первый программист, назначенный на проект, зашел в тупик на ранних этапах — он даже не перенес все справочники. Второй специалист продвинулся дальше: успешно перенес справочники с учетом доработок, штатное расписание, табель, часть документов. Но именно на этапе переноса логики расчета больничных мы окончательно «сломались». Эти расчеты были завязаны на стаж работы сотрудника, доплаты, последующую синхронизацию с Бухгалтерией — и требовали не просто программирования, а глубокого знания учета в ЗУП.
В итоге:
- первый программист не справился с базовой структурой,
- второй ушел в «тишину» на сложной доработке,
- мы не смогли довести дело до конца.
Почему так получилось
Мы сделали несколько ключевых ошибок:
- недооценили сложность конфигурации ЗУП и объем ручных доработок;
- не провели полноценный предварительный аудит базы и не обсудили с клиентом особенности логики учета;
- не привлекли специалиста по внедрению ЗУП, который разбирается в расчетах и методологии;
- попытались «вытянуть» весь проект силами одного программиста, хотя задача требовала командной работы;
- отнеслись к оценке поверхностно, надеясь «как-нибудь справиться» — в итоге не справились.
Какие выводы сделали
Самое главное — мы четко обозначили для себя специализацию. Мы — в первую очередь облачный провайдер и технический интегратор. Мы отлично разбираемся в настройке серверов, инфраструктуре, переносе баз, организации работы пользователей. Мы можем решать небольшие задачи по доработкам, у нас сильная линия консультаций по вопросам учета. Но когда речь идёт о масштабных проектах с глубокой доработкой логики учета, таких как ЗУП, нужно привлекать более узких специалистов.
Этот кейс подтолкнул нас к поиску партнёров, и сейчас мы ведем переговоры с командой, которая специализируется именно на сложных проектах по ЗУП и другим конфигурациям. Уже был успешный совместный проект, и если договоримся — мы сможем брать и выполнять такие задачи качественно, но уже в кооперации.
Чем всё закончилось
Клиенту мы вернули деньги (да, мы готовы брать ответственность за свои ошибки!). А в качестве компенсации за неудачный проект бесплатно перевели его Бухгалтерию из редакции 2.0 в 3.0 (в таких задачах у нас большой опыт, и конвертация прошла успешно). Проект с ЗУП — признали проваленным. Но зато вынесли из него честные и важные уроки.
Что в итоге
Иногда, чтобы чётко понять свою зону экспертизы, нужно в нее упереться лбом. Мы понимаем, где наша сила: в облаках, инфраструктуре, администрировании, стабильной работе сервисов. Мы не бросаем клиентов и честно признаем ошибки. Мы учимся и растём. Теперь у нас есть партнёрская сеть, с которой мы готовы браться и за масштабные задачи.
Так что приходите к нам за настройкой облака, а нужных специалистов по программной части найдем вместе.