Требования к внедряемой информационной системе

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

 В данном разделе  также приводят:

1. Перечень документов предъявляемых по окончании соответствующих стадий и этапов работ;
2. Вид и порядок проведения экспертизы технической документации (стадия, этап, объем проверяемой документации, организация – эксперт);
3. Программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы (при необходимости);
4. Перечень работ по метрологическому обеспечению на всех стадиях создания системы с указанием их сроков выполнения и организаций – исполнителей (при необходимости).

В разделе « Порядок  контроля и приемки системы»  указывают:

1. Виды, состав, объем и методы испытаний системы и ее составных частей;
2. Общие требования к приемке работ по стадиям, порядок согласования и утверждения приемочной документации.

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

В перечень основных мероприятий  включают:

1. Приведение поступающей  в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению);
2. Создание условий функционирования проекта, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;
3. Создание необходимых для функционирования  системы подразделений и служб;
4. Сроки и порядок комплектования штатов и обучения персонала.

В разделе « Требования к документированию» приводят:

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

В разделе « Источники  разработки» должны быть перечислены  документы и информационные материалы, на основании которых разрабатывалось  ТЗ и которые должны быть использованы при создании системы.

 

 

 

 

Техническое задание

 

Техническое задание (ТЗ) является основным документом, определяющим требования заказчика к системе, в соответствии с которыми осуществляется разработка программного продукта.

ТЗ может разрабатываться  на систему в целом и/или на ее составные части.

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

Основные подходы к  составлению ТЗ

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

1. Совместная работа.

2. Детальное описание  результата.

3. Механизм контроля за ходом проекта и квалификация консультантов.

4. Согласование результата.

Гибкость.

1.1 Совместная работа

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

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

Пример:

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

1.2 Детальное описание  результата

Много внимания нужно уделить  описанию результатов, которые заказчику  требуется получить после окончания  проекта, и обязательно зафиксировать  их в техническом задании. Например, вам необходимо получать отчет о  движении товара в соответствующих  аналитических разрезах ежедневно  в 9.00, то в ТЗ должны быть подробно описаны  параметры отчета (строки, аналитика, период, за который составляется отчет) и источники данных для его  формирования. Самое важное - не допустить  расширенного толкования технического задания, поэтому все источники  данных должны быть строго определены. В противном случае, если вы не указали  периода или источников данных, конечный результат может сильно отличаться от ваших ожиданий, а доработка  потребует дополнительных средств  и времени.

Результирующие показатели проекта представляют собой следующее.

1. Бизнес-модель вашей  компании.

2. Структура плана счетов

3. Список необходимых  документов (отчетов)

4. Структура данных для  генерации отчетов

5. Структура аналитических  кодов

6. Описание структуры  учетной модели в компании

7. Описание результата работы и методов приемки

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

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

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

Структура данных для подготовки отчетов (описание источников данных для  заполнения каждой строки отчета: субсчетов  рабочего плана счетов и конкретных значений аналитических кодов и  периода, из которого берутся данные).

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

 

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

Описание результатов  работ и методов их приемки (методика и сроки проверки и тестирования клиентом соответствия выполненных  работ написанному техническому заданию, протоколирование приемки).

Пример:

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

1.3 Механизм контроля за ходом проекта и квалификация консультантов

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

1.4 Согласование результата

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

Пример:

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

1.5 Гибкость

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

Пример:

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

2 «Подводные камни»

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

Со своей стороны, консультанты упрекают клиентов в неумении описать  ту задачу, которую необходимо решить с помощью АС, и в постоянном изменении своих требований к  системе. Такие противоречия можно  решить с помощью технического задания (ТЗ), которое регламентирует требования заказчика к будущей системе  и объем работ по ее внедрению.

2.1 Причины разногласий

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

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