«Первая встреча» — опытная эксплуатация

В этой статье я попытаюсь ответить на вопросы: зачем же всё-таки нужна опытная эксплуатация? Что она из себя должна представлять? И с чем приходилось сталкиваться нам как разработчикам программного обеспечения, внедряя продукт SIKE.Управление персоналом.
Когда можно переходить к этапу опытной эксплуатации? Когда разработчик принимает решение, что созданный продукт решает все задачи, которые ставились у истоков разработки. Когда возможные на текущий момент ошибки и сбои в работе с программой не повлекут негативного восприятия системы пользователями, а лишь помогут довести систему до совершенства. Когда продукт удобен и приятен в использовании.
Важный момент — определить, на каких данных и оборудовании будет испытываться система:
1. на тестовом наборе данных, оборудовании — заказчик предоставляет некий набор данных, оборудование, на которых будут проводиться всевозможные испытания.
2. на «рабочих» данных, оборудовании - в основном, при таком варианте работа ведётся параллельно в двух системах: на основной, установленной на предприятии, и на введенной в опытную эксплуатацию.

Как показывает практика, второй вариант наиболее предпочтителен, когда можно одни и те же данные увидеть в двух разных представлениях, и, соответственно, он более гибок и нагляден, и, как следствие, эффективен тот набор операций, который производится над этими данными и показывает результат. С технической точки зрения также есть положительные стороны. Тестовое оборудование может отличаться от промышленного хотя бы в плане своих настроек. При переходе к промышленной эксплуатации необходимо помнить об этом и настраивать аналогичные дополнительные функции, например, которые могут показать другую работу системы, нежели при опытной эксплуатации. На это необходимо обращать внимание заказчика.
И вот система SIKE.Управление Персоналом отдана на суд заказчику. Первые шаги работы и начинаются вопросы... Еще раз напомню, что управление персоналом далеко не тривиальный продукт, — помимо огромного количества схем, формул, расчетов, отчётов ещё и постоянно меняющееся законодательство в этой сфере. Пока разработчики делали, например, одну схему расчетов, законы быстро сменились, и вот на этапе опытной эксплуатации мы понимаем, что ряд алгоритмов требует переработки.
Необходимые доработки сделаны, начинаем сверять расчеты заработной платы, виды начислений, НДФЛ, страховые взносы. И опять вопросы! Садимся рядом с пользователем, начинаем искать разногласия — почему в прежней системе так, а у нас, в SIKE.Управлении Персоналом, по-другому. Причины выявленных расхождений разные и их много: то некоторые виды доходов предприятие раньше не облагало страховыми взносами по причине иной трактовки закона, то лишние вычеты предоставлялись или наоборот не предоставлялись работникам. Видов начислений в заработной плате также уйма — приходилось проводить ручное сопоставление начислений и удержаний в прежней системе и в системе SIKE.Управление Персоналом.
Отдельного упоминания заслуживает блок отчетности — если с унифицированными формами всё просто — как закон требует, так и оформляем, то с произвольной отчетностью возникают проблемы. Такие формы максимально подробно переводились на новое представление, но и такая работа не давала 100%-го сходства. И тут возникали вопросы, в основном, подпитываемые привычкой. То, что могли, доводили до сходства, где сходства не удавалось достичь, по разным причинам, — делали отчёты максимально удобными для конечного пользователя, учитывая все его пожелания.
Результатом опытной эксплуатации, как показывает практика внедрений системы SIKE.Управление Персоналом на промышленных предприятиях, является не только перечень системных ошибок или ошибок расчетов, вычислений, отклонений от технического задания, также может понадобиться модификация правил, схем, незначительная корректировка технических заданий. Стоит помнить, что корректировка технических заданий — это не ошибки проектирования, это корректировка моментов, которые стали видны только при непосредственной работе в системе, и возможность непосредственно изучить и устранить последствия ранее принятых не удобных проектных решений.
Итак, на этапе опытной эксплуатации заказчик отвечает за полный своевременный набор замечаний, выявленных при работе в системе, а исполнитель — за своевременное их устранение. Только такой тандем даст наиболее продуктивный результат. Можно с уверенностью сказать, что это самый эффективный этап, когда пользователь уже видит конечный продукт, и обе стороны настроены максимально продуктивно отработать этот отрезок времени внедрения системы, чтобы получить желаемый результат. И, как я уже говорила ранее в одной из статей, когда есть мотивация, результат не заставит себя ждать.
По окончании этапа опытной эксплуатации уже можно говорить о вводе системы в промышленную эксплуатацию, а такой документ, как «Акт ввода в промышленную эксплуатацию» поставит логическую точку данному этапу.