Технология внедрения программ системы 1С-Предприятие

От авторов
В предлагаемом материале представлен вариант технологии процесса внедрения, который мы хотели бы обсудить с коллегами из других франчайзинговых фирм.
По нашему опыту многие внедренцы (особенно начинающие) часто недостаточно четко строят организацию своих внедрений. В комплексных внедрениях проблема организации процесса ведения проекта стоит еще более остро. «Разрывы» в действиях сотрудников фирмы-франчайзи, причастных к выполнению задач автоматизации заказчиков могут привести к ошибкам, затягиванию сроков реализации, недовольству со стороны клиентов и т.п. Т. е. напрямую |могут сказаться на успехе внедрения.
В этой связи, на наш взгляд, назрела необходимость составить определенный набор требований для каждого этапа процесса внедрения, рекомендуемых к выполнению.
Наш материал построен следующим образом.
В начале мы предлагаем общую схему технологии внедрения системы программ 1С:Предприятие. Схема наглядно представляет последовательность выполнения задач. Далее применительно к схеме представлено краткое описание задач и набор типовых действий специалистов фирмы-франчайзи.
Конечно, линейность здесь довольно условна. Задачи могут пересекаться и объединяться. Многие из них растягиваются на несколько этапов. Не всегда представляется возможным выполнение задачи именно в предлагаемой последовательности и т.п.
Хотим выразить огромную благодарность нашим коллегам Жутаевой И., Бушуеву Е., Савину А., Лисогору Д., Мифтаховой М., за помощь в подготовке материала.
Ждем отзывов и предложений. Поляков А.В., Ожигов В.Л. Компания «ИКС Технологии» (г. Москва)
P.S.
При изложении технологии применены следующие ДОПУЩЕНИЯ:
· КЛИЕНТ уже ВЫБРАЛ СИСТЕМУ (если это касается внедрений категорий А и Б; см. задачу 7) с помощью грамотных специалистов фирмы-франчайзи и его выбору оказался правильным и рациональным;
· ВНЕДРЕНИЕ 1С:Предприятия - оказание франчайзинговых услуг любого объема: от решения частных задач автоматизации до внедрения «в комплексе». Минимальный набор услуг предоставляемых внедренческими фирмами определен Франчайзинговым договором (рекомендации по оказанию услуг см. [1, раздел 2.3], [2, раздел «Типовой набор услуг»]).
Литература, используемая в контексте ссылок:

1. Технология работы фирмы - «1С:Франчайзи». Д.И. Казачков.
2. Фирма - 1С:Франчайзи: система обслуживания клиентов. А.В. Поляков, Д.А. Лисогор, В.Л. Ожигов

Рекомендации по формам докумен­тов и методике их оформления см. [1, разделы 3.2.5, 7.2-7.10].
Проверяется наличие на складе ПРОГРАММНОГО ПРОДУКТА, в том случае, если внедрение включает его доставку и установку.
Ответственным за подготовку пакета документов и продуктов является руководитель отдела внедрения.
3. Определение исполнителей для начального этапа внедрения.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ определяет исполнителя для начального этапа работ у клиента.
Основные критерии выбора: специфика заказа, предметная специализация (компонента 1С:Предприятия, спектр выполняемых услуг и пр.) и опыт «кандидата», отраслевая специализация (наличие «готовых решений» и наработок на рынке деятельности заказчика), текущая загрузка.
Далее руководитель отдела внедрения ставит задачу исполнителю на выполнение работ, исходя из данных бланка соответствующего заказа и диалога с клиентом.
4. Предварительный анализ задачи.
ЭКСПЕРТ (в т.ч. технический специалист) должен подготовиться к предварительной беседе с клиентом на основе бланка заказа и обсуждения задачи с руководителем отдела внедрения.
Далее эксперт связывается с клиентом для выяснения деталей предстоящей автоматизации, договаривается о своем визите.
Эксперт должен взять с собой на заказ ПРОГРАММНЫЙ ПРОДУКТ (в случае надобности; и проверив работоспособность ключа защиты и носителей информации) и ПАКЕТ ДОКУМЕНТОВ, уточнив при необходимости правильность их заполнения.
5. Начальное обследование объекта.
ЭКСПЕРТ выезжает для выполнения заказа на основании договоренности с клиентом.
На месте экспертом уточняется предполагаемый спектр реальных задач внедрения (в т.ч. определяется круг первоочередных задач автоматизации). При необходимости вносятся соответствующие корректировки.
Здесь важно добиться одинакового понимания проблем, для чего уже на этом этапе начинается процесс ПОДГОТОВКИ специалистов заказчика к различным аспектам внедрения, его технологическим и организационным особенностям.
Эксперт при выполнении задачи 5 должен выяснить и зафиксировать всю необходимую информацию, в том числе для более точной оценки категории (см. задачу 7) и объема внедрения, а также возможностей клиента. Рекомендации по списку необходимых сведений см. [1, раздел 3.2.1].
Рекомендации по методике общения с клиентами и ведению переговоров см. соответственно [1, разделы 3.2.2 и 3.2.3].
6. Определить союзника внедрения.
Одной из важнейших задач ЭКСПЕРТА при выполнении задачи 5 является определение отв. лица или круга лиц со стороны заказчика, которые в первую очередь заинтересованы в успешной автоматизации. Тесное сотрудничество с ними при выполнении внедрения поможет сделать работу эксперта более продуктивной. Возможные варианты см. в задаче 13.
Кроме того, важно обеспечить: а) поддержку внедрения со стороны руководства заказчика, б) понимание важности внедрения как такового со стороны всех причастных к этому лиц заказчика.
ПРИМЕЧАНИЕ: Желательно определить союзника внедрения и заручиться его поддержкой (важно создать КОМАНДУ внедрения, в которую, кроме эксперта, входили бы представители заказчика) как можно раньше, однако не всегда на данном этапе это бывает возможным, особенно в комплексных внедрениях.
7. Анализ категории внедрения.
ЭКСПЕРТ на основании предварительной оценки делает вывод о предполагаемой категории внедрения.
ПРИМЕЧАНИЯ: 1) Понятие КАТЕГОРИИ внедрения вводится для их ранжирования, что предполагает а) более объективную оценку своих возможностей и ресурсов при обслуживании заказа, 6) более четкое следование дальнейшим этапам цепочки технологии внедрения.
2) Масштаб и сложность внедряемой системы, условия ее сопровождения должны быть адекватны уровню фирмы-франчайзи.
3) Границы представленных категорий внедрений весьма условны; часто в процессе реальной работы происходит плавный переход внедрений из младших категорий в старшие.
Категории внедрения
7А. Категория А:
Внедрение НАЧАЛЬНОГО УРОВНЯ.
ВОЗМОЖНЫЕ ЗАДАЧИ: установка и начальное обучение (гарантированный сервис) после чего пользователь предполагает начать самостоятельную работу с использованием типовой конфигурации, небольшие консультации по использованию типовой конфигурации системы.
ОБЪЕМ ЗАКАЗА: ограничивается обычно 10-ю часами работы специалистов франчайзи (1-2 визита).
ОСНОВНЫЕ ЗАКАЗЧИКИ: небольшие фирмы.
ТИП ПОСТАВКИ: работа обычно в локальной версии 1С: Предприятия на основе типовой конфигурации (используется чаще всего компонента 1С:Бухгалтерия).
7Б. Категория Б:
НЕБОЛЬШОЕ внедрение.
ВОЗМОЖНЫЕ ЗАДАЧИ: гарантированный сервис, конвертация базы при переходе с предыдущих версий программы (или других программ), незначительное изменение плана счетов, незначительная переделка форм и отчетов, обучение работе с программой, консультации и пр.
ОБЪЕМ ЗАКАЗА: от 10 до 50 часов работы специалистов франчайзи (2-10 визитов в течение месяца или разовые визиты в процессе эксплуатации системы).
ОСНОВНЫЕ ЗАКАЗЧИКИ: небольшие и средние фирмы.
ТИП ПОСТАВКИ: работа в локальной, 3-х пользовательской или сетевой версиях 1С:Предприятия (используются чаще всего 1-2
компоненты системы: ВЕДУЩЕЙ может быть любая из компонент в зависимости от профиля фирмы заказчика; 1С:Бухгалтерия при этом используется практически всегда).
7В. Категория В:
КОМПЛЕКСНОЕ внедрение.
ВОЗМОЖНЫЕ ЗАДАЧИ: комплексная поэтапная работа: всестороннее обследование объекта, составление ТЗ, разработка конфигурации, обучение персонала, ввод конфигурации в эксплуатацию, подготовка пользовательской документации, комплексное сопровождение и пр.
ОБЪЕМ ЗАКАЗА: не менее 30 часов работы специалистов франчайзи.
ОСНОВНЫЕ ЗАКАЗЧИКИ: средние и достаточно крупные фирмы;
ТИП ПОСТАВКИ: работа в сетевой версии 1С:Предприятия (используется чаще всего комплексная конфигурация, ВЕДУЩЕЙ может быть любая из компонент в зависимости от профиля фирмы заказчика).
ПРИМЕЧАНИЯ: 1) Необходимо четкое понимание руководством фирмы-франчайзи следующего непременного условия: Только наличие соответствующей инфраструктуры позволяет рассчитывать на успешную работу над внедрениями категории В.
2) Внедренческая структура должна быть готова: а) подключиться к автоматизации системы у клиента на любом из ее этапов, б) к возможной замене конкретных исполнителей проекта.
Для внедрений КАТЕГОРИЙ А и Б: задачи 8-11.
8. Решение первоочередных задач автоматизации.
ЭКСПЕРТ должен в первую очередь решить наиболее острые и неотложные задачи автоматизации заказчика (и желательно при первом же визите), которые были определены при начальном обследовании объекта (см. задачу 5).
См. также рекомендации по выполнению работ задачи 15.
9. Задача «закрепления» клиента.
ЭКСПЕРТ и фирма-франчайзи в целом в своей работе должны РУКОВОДСТВОВАТЬСЯ УСТАНОВКОЙ: «Каждый клиент должен стать постоянным для эксперта и фирмы и оставаться им на всем цикле эксплуатации 1С:Предприятия».
Оперативное и квалифицированное решение первоочередных задач внедрения - это не только качественное выполнение текущего заказа, но и работа «на перспективу».
ЭКСПЕРТ во время работы над заказом должен:
· продемонстрировать высокий профессиональный уровень (рекомендации по обеспечению качества выполнения работ см. [1, раздел 3]) и высокий уровень общения для создания благоприятной среды, в которой будет проходить внедрение (см. рекомендации [1, разделы 3.2.2, 3.2.3]);
· предложить свои идеи по усовершенствованию системы, а возможно и помощь в разработке стратегии автоматизации клиента (что является новым качеством внедрения фирмы-франчайзи);
· подробно проинформировать клиента о своей фирме, ее услугах и возможностях, инициалы ответственных по направлениям, системе сопровождения пользователей и т.п. Оперативность и точность получения последующей от клиента информации обеспечит более оперативную реакцию на обращения.
ПРИМЕЧАНИЕ: Задача «Закрепления клиента» (см. УСТАНОВКУ в задаче 9) стоит на всех этапах внедрения и для всех его категорий.
10. Закрытие выполненных работ.
Для закрытия выполненных работ ЭКСПЕРТ должен:
· оформить и подписать у отв. представителя заказчика весь пакет соответствующих документов и протоколов (акты о выполнении работ, другие первичные документы, специализированные документы и протоколы);
· получить расчет от заказчика (или проконтролировать поступление средств на расчетный счет в случае безналичной оплаты).
Далее ЭКСПЕРТ вносит перечень проделанных у клиента работ в ОТЧЕТ ЭКСПЕРТА (рекомендации по формам такого отчета см. [1, раздел 7.12], другие рекомендации по отчетности экспертов см. [2, раздел «Типовая организация обслуживания клиентов»]). Отчет раз в неделю лично сдается РУКОВОДИТЕЛЮ ОТДЕЛА ВНЕДРЕНИЯ и комментируется экспертом. Отчет (включая его устную форму) в данном случае служит для регулярного контроля процесса внедрения. Руководитель отдела внедрения визирует сданный экспертом отчет.
Только после этого заказ можно считать ВЫПОЛНЕННЫМ и ЗАКРЫТЫМ.
Здесь полезны рекомендации по типу документов и их оформлению [1, раздел 3.2.5].
11. Заказчик идет на дальнейшее сотрудничество?
Производя закрытие выполненных работ, ЭКСПЕРТ должен еще раз поинтересоваться у отв. представителей заказчика о планах на дальнейшее сотрудничество. Если заказчик взял время на обсуждение, необходимо договориться о дате возможных контактов. Эксперт должен поставить в известность РУКОВОДИТЕЛЯ ОТДЕЛА ВНЕДРЕНИЯ о дальнейших планах заказчика.
Для внедрений КАТЕГОРИИ Б: задачи 12-16.
12. Перспективное планирование работ.
ЭКСПЕРТ в переговорах с отв. представителями заказчика должен согласовать предполагаемый порядок дальнейших действий и составить на основе этого проект ( ПЛАНА ) ГРАФИКА РАБОТ (по возможности максимально подробно с указанием предполагаемых сроков).
Далее эксперт должен оговорить с заказчиком даты и время ближайших контактов.
13. Оценка «перспективности» заказчика.
ЭКСПЕРТ в процессе сотрудничества с заказчиком вырабатывает оценку его «индивидуальных» особенностей и перспективности внедрения. ОЦЕНКА «перспективности» заказчика оформляется в виде рабочего документа для внутреннего пользования и передается руководителю отдела внедрения. Далее сведения «Оценки...» должны размещаться в базе сводных данных о клиенте (данные исключительно для внутреннего пользования с ограничением прав доступа к ним).
Примеры полей «Оценки...» (возможны дополнения):
1. Название организации, адрес, телефон;
2. Контактные лица;
3. Масштаб организации: а) небольшая, б) средняя, в) крупная. Комментарии к каждому варианту;
4. Наличие удаленных отделений и филиалов, их количеств, местонахождение. Комментарии к каждому варианту;
5. Численность рабочих мест (в т.ч. одновременно работающих в системе). Комментарии;
6. Объем документооборота;
7. Профиль деятельности: а) розничная торговля, в) оптовая торговля, в) производство, г) бюджетная структура, д) другое. Комментарии к каждому варианту;
8. Отраслевое направление деятельности. Комментарии;
9. Целесообразный масштаб автоматизации по оценке эксперта: а) небольшой, б) довольно большой, в) очень боль­шой. Комментарии к каждому варианту;
10. Клиент оценивает перспективный масштаб автоматизации: а) в основном правильно, б) недостаточно правильно, в) неправильно. Комментарии к каждому варианту;
11. Платежеспособность клиента: а) готов платить всегда, б) готов платить при строгом контроле работ и их стоимости, в) платит «со скрипом», г) практически не готов платить. Комментарии к каждому варианту;
12. Кто из отв. представителей клиента в первую очередь заинтересован во внедрении: а) РУКОВОДИТЕЛЬ (зам. руководителя), б) ПРОГРАММИСТ (системный администратор и т.п.), в) БУХГАЛТЕР, г) МЕНЕДЖЕР (руково­дитель направления фирмы и т.п.), д) Другие сотрудники. Комментарии к каждому варианту;
13. Кто из отв. представителей клиента не поддерживает внедрение: а) РУКОВОДИТЕЛЬ (зам. руководителя), б) ПРОГРАММИСТ (системный администратор и т.п.), в) БУХГАЛТЕР, г) МЕНЕДЖЕР (руководитель направления фирмы и т.п.), д) Другие сотрудники. Комментарии к каждому варианту;
14. Адекватность восприятия происходящего и уровень общения отв. лиц клиента в процессе внедрения: а) работается комфортно, б) работается нормально, в) работается некомфортно г) работать невозможно (скандальный клиент). Комментарии к каждому варианту;
15. Инициалы отв. эксперта от франчайзи.
ПРИМЕЧАНИЕ: Желательно составить подобную оценку как можно раньше. но в дальнейшем оценка может корректироваться.
14. Выработка системы отношений с заказчиком.
ЭКСПЕРТ в согласовании с руководителем отдела внедрения на основе данных, полученных при выполнении задач 12 и 13, вырабатывает модель поведения по отношению к клиенту.
Далее оговаривается СИСТЕМА ОТНОШЕНИЙ (договорные и финансовые) заказчика и исполнителя, определяются условия взаимодействия, порядок разрешения споров и противоречий. Здесь полезными будут рекомендации и примеры форм документов [1, разделы 3.2.3, 3.2.5, 7.2-7.10].
Затем согласуется ГРАФИК РАБОТ, который оформляется в виде рабочего документа с визированием со стороны заказчика и исполнителя (в редких случаях допускается устная форма договоренностей).
Выполняя весь цикл согласований задачи 14, эксперт при необходимости может обращаться за советами к руководителю отдела внедрения.
ПРИМЕЧАНИЕ: График работ может корректироваться по условиям выполнения текущих работ внедрения.
15. Выполнение текущих работ.
Задача ЭКСПЕРТА при выполнении работ - добиться максимальной эффективности работы системы заказчика, исходя из существующих условий. Рекомендации по обеспечению качества выполнения работ см. [1, раздел 3]).
Эксперт для данной категории внедрения является: а) непосредственным исполнителем внедрения, б) координатором внедрения от исполнителя с довольно широким кругом полномочий при решении вопросов и разрешении проблем.
Необходимо понимание экспертом технологической цепочки своей фирмы, ее возможностей, уровня и наличия специалистов для принятия четких и оперативных действий по всему комплексу обслуживания со стороны внедренческой фирмы.
Эксперт должен заслужить хорошую репутацию у заказчика профессиональной работой, заинтересованностью при решении проблем заказчика, пунктуальностью, высоким уровнем общения, опрятным внешним видом и т.п. НЕОБХОДИМО постоянно поддерживать репутацию и авторитет своей фирмы при выполнении работ. Этому, в частности, способствуют: рациональное использование времени работы с клиентом (что-то необходимо оставлять на проработку сотрудникам пользователя, ставить перед персоналом клиента конкретные цели и задачи) и основных усилий по внедрению (например, обучение штатного программиста заказчика, способного в дальнейшем обслуживать систему), возможные небольшие переработки.
Важным здесь является также необходимость обеспечения информированности о всех аспектах внедрения причастных к этому лиц со стороны заказчика.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ должен осуществлять постоянный контроль качества выполнения работ. Рекомендации по контролю качества обслуживания см. [1, раздел З.З.З].
16. Закрытие выполненных работ.
По аналогии с задачей 10.
Производя закрытие выполненных работ, ЭКСПЕРТ должен еще раз поинтересоваться у отв. представителей заказчика о планах на дальнейшее сотрудничество и оговорить даты и время ближайших встреч.
Для всех категорий внедрений: задача 17.
17. Система сопровождения пользователей.
На фирме-франчайзи должна быть поставлена отлаженная СИСТЕМА СОПРОВОЖДЕНИЯ ПОЛЬЗОВАТЕЛЕЙ. Это один из ключевых элементов долгосрочного сотрудничества с клиентом.
Элементы системы сопровождения пользователей: линия консультаций, обновления из офиса и С выездом к клиенту, ИТС, специализированные семинары, абонементное обслуживание, сетевой и технический консалтинг и поддержка и пр. (рекомендации по сопровождению пользователей см. [2, раздел «Типовой набор услуг»]).
Для внедрений КАТЕГОРИИ В: задачи 18-42
Предварительный этап внедрения
18. Выработка системы отношений с заказчиком.
В переговорах с отв. представителями клиента вырабатывается СИСТЕМА ОТНОШЕНИЙ (договорные и финансовые) заказчика и исполнителя, определяются условия взаимодействия, порядок разрешения споров и противоречий. Здесь полезными будут рекомендации и примеры форм документов [1, разделы 3.2.3, 3.2.5, 7.2-7.10].
Со стороны франчайзи основные переговоры обычно ведет РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ (здесь и далее: или руководитель группы по работе над комплексными заказами для крупных внедренческих структур) с возможным привлечением руководителя фирмы и ведущего эксперта.
19. Определение постановщика проекта.
РУКОВОДИТЕЛЬ ОТДЕЛА ВНЕДРЕНИЯ определяет кандидатуру ПОСТАНОВЩИКА проекта. При этом учитываются мнения и пожелания: отв. представителей заказчика, руководителя внедренческой фирмы, возможных «кандидатов».
Кандидатура ПОСТАНОВЩИКА проекта выбирается из числа экспертов наиболее высокого класса фирмы-франчайзи. Это должен быть опытный специалист-универсал (аттестованный чаще всего по нескольким компонентам 1С:Предприятия). Выбор должен также учитывать: отраслевую специализацию эксперта (наличие «готовых решений» и наработок на рынке деятельности заказчика), текущую загрузку.
ЭТАП 1 внедрения: Комплексное обследование, выбор системы, составление ТЗ и графика работ
20. Договор на обследование объекта и составление ТЗ.
РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ и отв. представителями заказчика вырабатывается и подписывается ДОГОВОР НА ОБСЛЕДОВАНИЕ ОБЪЕКТА И СОСТАВЛЕНИЕ ТЗ (по результатам договоренностей задачи 18). В нем оговариваются только условия и сроки выполнения этапа I внедрения: комплексное обследование, составление ТЗ и плана графика работ. Только после выполнения этапа I внедрения можно детально обсуждать условия и сроки выполнения последующих этапов внедрения (хотя, во многих случаях с заказчиком приходиться предварительно обсуждать ориентировочный бюджет проекта автоматизации).
Продолжительность выполнения этапа I внедрения составляет обычно не менее двух недель.
Здесь могут быть полезны рекомендации по форме договора [1, раздел 7.5].
21. Комплексное обследование объекта.
Этап I внедрения выполняется в основном ПОСТАНОВЩИКОМ проекта. Однако, для обсуждения специфических вопросов внедрения (в т. ч. вопросов технического характера), окончательной оценки трудоемкости написания конфи­гу­рации постановщик должен провести соответствующие консультации с другими специалистами и кодировщиками.
Задача ПОСТАНОВЩИКА при выполнении этапа I внедрения -во взаимодействии с отв. представителями заказчика выработать максимально эффективную модель автоматизированной системы учета предприятия, исходя из существующих условий (бюджет проекта, сроки).
Эксперт-постановщик проекта для внедрений категории В является а) непосредственным исполнителем, как минимум, этапа I внедрения, б) координатором внедрения от исполнителя на всех его этапах с широким кругом полномочий при решении вопросов и разрешении проблем.
Эксперт при выполнении задачи 21 должен выяснять и зафиксировать всю необходимую информацию. Эти сведения станут основой для правильного выбора системы, успешного составления ТЗ и плана графика работ (рекомендации по списку необходимых сведений см. [1, раздел 3.2]). Они помогут также при составлении ОЦЕНКИ ПЕРСПЕКТИВНОСТИ ЗАКАЗЧИКА (см. задачу 23).
Здесь и далее см. также рекомендации задачи 15 «Выполнение текущих работ».
22. Задача «закрепления» клиента.
По аналогии с задачей 9.
23. Оценка «перспективности» заказчика.
По аналогии с задачей 13.
24. Выбор системы.
На основе данных, полученных при выполнении комплексного обследования (задача 21) ПОСТАНОВЩИК (в согласовании с руководителем отдела внедрения и техническими специалистами фирмы-франчайзи) вырабатывает предложение для заказчика о возможных вариантах поставки системы. Предложение описывает характеристики предлагаемых вариантов и указывает их стоимость. Рекомендации по процедуре выбора системы см. [2, раздел «Типовой набор услуг»].
Заказчик принимает решение о том, на основе какого варианта поставки будет производиться внедрение. Закупка же самого продукта не обязательно возможна именно здесь. Она может состояться и несколько позже или в принципе не состояться, если заказчика не будут удовлетворять результаты выполнения этапа      I внедрения.
25. Составление ТЗ и графика работ.
ТЗ является концептуальным документом, подтверждающим одинаковый подход сторон к пониманию и решению конкретных задач по автоматизации учетного процесса.
ЭКСПЕРТ- постановщик проекта является отв. исполнителем задачи 25. При этом он должен добиться от руководства заказчика, чтобы с ним тесно сотрудничал опытный специалист (или группа специалистов) заказчика, хорошо понимающий особенности технологии работы и учета своего предприятия. Эксперт обязан предупредить о высокой ответственности заказчика за согласование разрабатываемого ТЗ.
Тщательно проработанное и правильно составленное ТЗ значительно снижает стоимость внедрения и сокращает сроки его выполнения, что в свою очередь является хорошей базой для дальнейшего сотрудничества с заказчиком.
При составлении ТЗ следует учитывать, что оно может быть успешным только в том случае, если основные трудозатраты по его составлению пришлись на долю представителей заказчика. Работа эксперта на данном этапе в основном состоит в правильном понимании потребностей заказчика, их соотнесении с реальными возможностями программного продукта, а также в оформлении пожеланий заказчика в виде документа.
С другой стороны, не следует забывать, что комплексное внедрение зачастую предполагает внесение серьёзных изменений в бизнес-процесс заказчика. Естественно, не каждый заказчик готов самостоятельно оценить необходимость и масштаб подобных изменений. Поэтому роль постановщика задачи в подобных случаях должна состоять не только и не столько в терпеливом выслушивании пожеланий заказчика, сколько в выявлении тех особенностей учета, которые могут помешать внедрению новых информационных технологий. При выявлении таковых необходимо, прежде всего, указать заказчику на возможную нестыковку и предложить способы ее устранения.
При выполнении задачи 25 ЭКСПЕРТ должен регулярно консультироваться с РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ (в том числе при определении предполагаемых сроков выполнения и стоимости работ по следующему этапу внедрения).
26. Закрытие этапа 1 внедрения.
ЭКСПЕРТ- постановщик проекта должен подписать ТЗ и график работ у отв. представителя заказчика (в данном случае чаще всего им является один из руководителей фирмы). Далее по аналогии с задачами 10 и 16.
27. Заказчик идет на дальнейшее сотрудничество?
По аналогии с задачей 11.
ЭТАП II внедрения: Разработка конфигурации и ввод ее в эксплуатацию
28. Договор на внедрение.
РУКОВОДИТЕЛЕМ ОТДЕЛА ВНЕДРЕНИЯ и отв. представителями заказчика вырабатывается и подписывается ДОГОВОР НА ВНЕДРЕНИЕ (по результатам подписанных ТЗ и плана графика работ). В нем оговариваются условия и сроки выполнения этапа II внедрения, который включает: разработку конфигурации, тестирование конфигурации, обучение администраторов и персонала, подготовку пользовательской документации, сдачу-приемку конфигурации, опытную эксплуатацию.
Продолжительность выполнения этапа II внедрения составляет обычно не менее одного месяца.
Рекомендации по форме составляемого договора см. [1, раздел 7.6].
29. Есть ли потребность в дополнительных исполнителях?
Комплексное внедрение, как правило, предполагает участие группы экспертов. Ведущая роль, как уже говорилось, принадлежит ПОСТАНОВЩИКУ проекта. Кроме него, в разработке может принимать участие один или несколько специалистов-кодировщиков, главная задача которых состоит в написании тех документов и отчетов, которые требуются постановщику. На завершающем этапе потребуется специалист по обучению персонала заказчика.
К этой работе полезно привлечь эксперта (не кодировщика) имеющего больше опыта в общении с людьми, нежели с программированием.
30. Определение и подключение дополнительных исполнителей.
Проекты по внедрению, в которых принимают участие несколько исполнителей, гораздо более сложны в управлении, однако именно в таких проектах эффективность работы фирмы наиболее высока. В тех случаях, когда мы имеем большой объем работ, причем зачастую в смежных областях (например, стыковка с торговым оборудованием и сложный бухгалтерский учет), либо проект имеет жесткое ограничение по срокам, оправдано привлечение к работе нескольких специалистов. При этом возможно назначение РУКОВОДИТЕЛЯ ПРОЕКТА (особенно это характерно для крупных и многогранных задач), которому передаются все необходимые полномочия и на которого возлагается вся полнота ответственности за его выполнение. В разных случаях функции руководителя проекта могут осуществлять ПОСТАНОВЩИК или руководитель группы по работе над комплексными заказами.
Вопросы по определению и подключению дополнительных исполнителей и возможному назначению руководителя проекта решает руководитель отдела внедрения в консультациях с постановщиком (при возможном обсуждении с руководителем фирмы-франчайзи).
31. Разработка конфигурации.
На основе ТЗ разрабатывается конфигурация, учитывающая конкретные потребности заказчика.
При разработке конфигурации силами группы специалистов большое значение имеет координирование общей работы. В этой связи, целесообразно, чтобы структура данных описывалась постановщиком. Создается макетная конфигурация, в которой не прописаны модули, а лишь заданы основные типы данных и написаны черновые варианты описаний к документам, чтобы в дальнейшем эта информация была руководством к действию отдельным исполнителям.
Никакой тип данных не должен меняться без согласования с постановщиком, иначе непредвиденные изменения в данных, осуществленные разными людьми, могут вступить в противоречие и затянуть выполнение задачи в целом. Изменения процедур и функций в Глобальном модуле тоже не допустимы без согласования с тем исполнителем, который эту процедуру или функцию написал. Для этого желательно, чтобы в виде ремарок, в Глобальном модуле было видно авторство процедур и функций.
Каждый исполнитель должен понимать идеологию задачи, а не только «свой кусок». Для этого постановщик так формулирует информацию о задаче, чтобы каждый исполнитель понял ее взаимосвязи (но не в ущерб конфиденциальности).
Безусловно, на этапе составления ТЗ не исключены ошибки. Поэтому, в процессе создания конфигурации эксперт обязан внимательно проработать каждый пункт ТЗ.
В случае необходимости или явной предпочтительности применения механизмов отличных от тех, которые указаны в ТЗ, эксперт имеет право отступать от таких механизмов и требований ТЗ в рамках предварительной договоренности с заказчиком.
В случае необходимости внесения принципиальных изменений в ТЗ, эксперт инициирует дополнительные переговоры с представителями заказчика для разрешения всех появившихся вопросов. Уровень представителей со стороны Заказчики и Исполнителя определяется исходя из конкретно возникшей ситуации.
32. Тестирование.
Целесообразно предварительное тестирование вновь разработанной конфигурации проводить на специально собранном для этой цели полигоне на территории Исполнителя с обязательным присутствием представителей Заказчика.
В случае невозможности проведения предварительного тестирования на полигоне Исполнителя по техническим или организационным причинам, тестирование проводится на территории и оборудовании Заказчика.
В любом случае составляется и подписывается обеими сторонами акт, отражающий итоги проведенных испытаний.
На этапе тестирования конфигурация проверяется на соответствие всем пунктам ТЗ в их последней редакции. Выявляются нестыковки и отклонения в реально существующей конфигурации и требований указанных в ТЗ.
При проверке документов, необходимо заводить данные близкие к реальным, т.е. осуществлять проверку по «живым» документам. Это позволяет избежать мелких, но досадных ошибок (например: не хватает разрядности у числовых переменных, не «влезает» наименование и т.п.). Если справочник имеет несколько уровней, то нужно сразу создать группы во избежание ошибок, связанных принадлежностью элементов к группам. Если с документом, предполагается работа нескольких пользователей с разными правами, то необходимо сразу создать соответствующие наборы прав, особенно если разделение доступа производится средствами языка.
После тестирования проводится совещание с участием представителей Заказчика и Исполнителя, на котором принимаются решение о дальнейших действиях (в т.ч. по выявленным отклонениям).
33. Обучение администраторов.
Администраторы принимают активнейшее участие в тестировании разработанной конфигурации. Именно на этом этапе они получают основную часть требуемых знаний. В случае необходимости проводится дополнительное обучение администраторов силами квалифицированных специалистов внедренческой фирмы. Темы обучения, объем и форма преподаваемого материала определяется отдельно для каждого конкретного проекта.
Необходимо учитывать, что администраторы информационной базы заказчика являются очень значимыми звеньями в процессе эксплуатации системы. Значительное количество обращений пользователей на линию консультаций происходит именно из-за отсутствия у заказчика хорошо подготовленных специалистов, способных квалифицированно решать задачи ежедневного обслуживания информационной системы.
34. Обучение персонала.
Подготовку специалистов заказчика, как уже говорилось, целесообразно начинать уже на первых стадиях внедрения и вести эту работу на всех его этапах. Специализированное обучение персонала работе на разработанной конфигурации проводится квалифицированными экспертами внедренческой фирмы. Персонал должен получить все необходимые для корректной эксплуатации системы знания и навыки. Именно качественная подготовка персонала во многом определяет успех автоматизации. В некоторых случаях бывает полезным в завершении обучения проводить сертификационные экзамены.
См также рекомендации по обучению[2, раздел «Типовой набор услуг»].
35. Подготовка пользовательской документации.
Обучение пользователей не освобождает внедренцев от подготовки пользовательской документации. Эта задача начинается с описаний к справочникам и документам, которые делаются еще на этапе создания макетной конфигурации (т.е. при выполнении задачи 31). В процессе написания алгоритмов для проведения документов, эти описания пополняются, затем редактируются и собираются в один файл (документ). Файл желательно снабдить для наглядности иллюстрациями.
36. Сдача-приемка конфигурации.
Сдача-приемка конфигурации осуществляется на территории Заказчика в присутствии его представителей и представителей Исполнителя. Конфигурация проверяется на соответствие всем пунктам ТЗ. По факту сдачи-приемки составляется и подписывается соответствующий акт.
37. Опытная эксплуатация.
Опытная эксплуатация представляет собой пробную эксплуатацию системы в продолжение заранее оговоренного срока. Во время опытной эксплуатации Исполнитель обязуется обеспечить непрерывный контроль функционирования системы и в случае необходимости устранить возможные ошибки в работе конфигурации (назначается эксперт отв. за выполнение данной задачи). После проведения опытной эксплуатации составляется и подписывается соответствующий акт.
Важно понимание того, что во время опытной эксплуатации неизбежно возникновение ошибок как по вине сотрудников заказчика, отвечающих за эксплуатацию системы, так и в результате ошибок в конфигурации, не выявленных на этапе тестирования.
Изменения, вносимые в конфигурацию на этапе опытной эксплуатации, очень ответственная задача. Если конфигурация писалась коллегиально, необходимо тщательно проанализировать, не приведут ли эти изменения к ошибкам в работе документов, написанных другим исполнителем.
38. Проработка условий выполнения этапа III внедрения.
Заказчик и Исполнитель прорабатывают условия сопровождения системы. Обычно результатом проработки становится подготовка и подписание договора на абонементное обслуживание.
39. Закрытие этапа II внедрения.
По аналогии с задачами 10 и 16.
40. Заказчик идет на дальнейшее сотрудничество?
По аналогии с задачей 11.
ЭТАП III внедрения: Комплексное сопровождение внедренной системы
41. Договор на комплексное сопровождение.
Оптимальный вариант подобного договора: фиксированная сумма в месяц за оговоренные действия специалистов франчайзи по отслеживанию состояния базы, исправление своих же мелких погрешностей и ошибок пользователей, которые неизбежны на начальном этапе реальной эксплуатации системы. Исправление же ошибок, допущенных при проектировании и разработке ТЗ (а таковые нередки и, как правило, являются обоюдными), а также доработку конфигурации лучше всего приравнять к разработке (т.е. проводить по расценкам договора на внедрение). Это важный момент и он должен быть предусмотрен в договоре на сопровождение.
42. Абонементное обслуживание.
Существует две модели выполнения задачи 42.
Реактивная модель предполагает, что действия специалистов франчайзи по сопровождению системы осуществляются после возникновения проблемы.
Активная модель предполагает проведение профилактических действий, предупреждающих появление проблем, связанных с эксплуатацией информационной системы.
Естественно, вторая модель предполагает более активные действия. Поэтому такая форма абонементного обслуживания несколько дороже по стоимости. Однако, как показывает опыт, безотказная работа хорошей информационной системы с лихвой окупает все затраты на ее эксплуатацию.

Методические материалы по разработке технического задания на привязку программ 1С

Фраичайзи выделяются два вида, по трудоемкости и сложности, нередко превосходящие остальные - это привязка и внедрение программ 1С. Кроме того, привязка и внедрение отличаются еще одной существенной деталью. При их выполнении, в процессе перевода предприятия (организации) на автоматизированный учет принимают участие и учетный персонал организации и специалисты франчайзи, т. е. появляется человеческий фактор. В тоже время услуги другого рода продажа программных продуктов, доставка, установка, консультационные услуги и ряд других, характерны тем, что функции франчайзи и клиента четко разделены, и франчайзи не несет ответственности за процесс автоматизации учета на предприятии (организации) с использованием программ 1С.
Почему возникает потребность в привязке программ 1С. В бухгалтерском учете выделяется группа учетных задач, которые имеют прозрачную содержательную сущность и строго регламентированные алгоритмы решения. Такие задачи базируются на нормативных документах по организации бухгалтерского учета, мало зависят от вида деятельности предприятия и особенности хозяйственной деятельности. Программы 1С в значительной степени автоматизируют именно эти задачи, что позволяет им стать универсальными и применяться с незначительной адаптацией. В то же время в учете имеется множество задач, отражающих специфику видов деятельности, предполагающих многовариантность организации и методов ведения учета. Задач такого рода в программах 1С значительно меньше, чем унифицированных, высока вероятность, что их надо дорабатывать при привязке к предприятию (организации).
Программа 1С рассматривается как система, для которой установлены назначение, область применения, условия и правила использования без изменений или с незначительной доработкой к конкретным условиям.
Что такое привязка и внедрение Определимся в терминологии. Что такое привязка и внедрение? Под привязкой понимается процесс приспособления заложенных в программах 1С проектных решений по функциональной части, информационному и программному обеспечению к условиям конкретного предприятия (организации).
Привязка может осуществляться посредством адаптации системы или ее доработки.
На практике чаще всего применяется комбинация этих способов.
Под адаптацией понимается настройка программ 1С на конкретные условия применения с помощью установки значений предусмотренных переменных параметров.
Под доработкой понимается конфигурирование системы, замена отдельных ее компонентов, которые не удовлетворяют условиям конкретного применения и разработка дополнительных проектных решений.
Внедрение системы представляет собой процесс постепенного перехода от существующих способов и техники учета к новым, на основе использования программ 1С, прошедших привязку. Внедрение может осуществляться достаточно длительное время.
При внедрении программ 1С, как и любой другой человеко-машинной системы, происходит окончательное согласование состава и содержания автоматизированных функций, распределение учетных функций между человеком и машиной, согласование информационных взаимосвязей задач.
Все это может вызвать необходимость разработки дополнительных проектных решений, что увеличит объем работ по привязке.
Внедрение может производиться как на основе программ 1С, предварительно прошедших адаптацию и доработку, так и на основе только адаптированной типовой конфигурации.
Привязка и внедрение это два самостоятельных этапа работ, каждый из которых должен регулироваться собственными регламентирующими документами.
Работы по привязке и внедрению распределяются на следующие этапы:
· обследование объекта
· организационные мероприятия
· разработка технического задания
· адаптация и доработка программ 1С к специфике предприятия (организации)
· внедрение программного продукта
В данных методических материалах будет рассматриваться только один этап: разработка технического задания.
Для чего нужно техническое задание? 1. В техническом задании устанавливается точный состав и содержание работ по привязке программ 1С к объекту. Заказчик их утверждает в составе технического задания, Работы, выходящие за рамки технического задания и потребность в которых возникла на этапе внедрения, оплачиваются и выполняются по дополнительному соглашению.
2. Устанавливается состав изменений в методике и организации учета на предприятии (организации), в связи с переходом на автоматизированный учет на базе программ 1С. Заказчик их утверждает, и их выполнение является обязательной предпосылкой внедрения.
3. Устанавливается порядок приемки программ, прошедших привязку и порядок контроля правильности функционирования программ.
4. Сама необходимость разработки и оформления технического задания заставляет франчайзи и заказчика более тщательно разобраться в задачах привязки, что, в конечном счете, приводит к повышению качества работ, сокращению сроков проведения, уменьшает возможность возникновения конфликтов с заказчиком.
5. С помощью технического задания возможно избежать изменений, которые являются следствием субъективного подхода к решению отдельных вопросов работниками бухгалтерского аппарата, сложившимся на предприятии традициями существующей системы обработки учетной информации и могут повлечь снижение эффективности внедрения.
Техническое задание разрабатывается на основании результатов обследования объекта и выявленных отклонений действующей системы организации и методологии учета на предприятии (организации) от предусмотренных в программах 1С.
Следует четко проводить границу между решениями программы 1С, которые будут сохранены при внедрении, и решениями, которые будут переработаны при привязке. В техническом задании отражаются решения, подлежащие переработке.
Техническое задание устанавливает основные требования, которым должна удовлетворять программа 1С после ее адаптации и доработки. Договорные документы должны содержать ссылки на техническое задание
Естественно, что на этапе обследования объекта учетный персонал должен быть ознакомлен с принятыми в программах 1С функциональными и информационными решениями, они должны быть ему понятны. Тогда и все положения технического задания воспринимаются заказчиком вполне осознано. Техническое задание - один из важнейших документов, регулирующих отношения между франчайзи и клиентом.
В методических указаниях устанавливаются требования к составу, содержанию и оформлению технического задания на привязку программ 1С.
Далее изложены возможные требования к составу и оформлению технического задания.
Состав технического задания Основание для разработки.
Назначение разработки.
Методологические основы решения задач.
Функциональные спецификации и описание алгоритмов.
Условия эксплуатации.
Порядок контроля работоспособности программ и их приемка.
Этапы разработки.
Разделы технического задания Основание для разработки.
В данном разделе идентифицируется работа и ее заказчик, акцентируется внимание на организационных и методических материалах положенных в основу работы.
В разделе указываются:
· наименование работы, краткое ее содержание, условное обозначение, если оно имеется;
· наименование организации заказчика;
· перечень документов, на основании которых ведется разработка с указанием полного названия этих документов и данных об их утверждении;
· наименование программы 1С и ее условное обозначение, принятой для проведения привязки к объекту;
· перечень исходных материалов, использованных при разработке технического задания, в том числе материалы обследования, нормативно-технические документы, рекомендованные для использования, методические, проектные, научно-исследовательские разработки и т.п.; по каждому из приведенных материалов указываются данные об их утверждении, а также - какие именно разделы документов использованы;
· место проведения работ по привязке программ 1С.
Назначение разработки.
В разделе указывается функциональное назначение разработки. Программы 1С имеют определенное функциональное назначение. Они ориентированы на реализацию регламентированного состава учетных задач с фиксированными алгоритмами решения. В разделе приводятся наименования задач в составе программ 1С, которые будут переработаны. Здесь же перечисляются задачи, которые будут дополнительно разработаны и включены в состав программ 1С.
Указываются отклонения от программ 1С по содержанию задач.
Поясняется, каким образом будут использоваться результаты решения переработанных задач.
Методологические основы решения задач В этом разделе должна быть приведена аргументация по всем изменениям и дополнениям к действующим в программах 1С методологическим установкам.
По задачам приводится краткое описание проектных решений по методологии и организации автоматизированного выполнения учета. Это снижает возможность разработки ошибочных решений.
Если в программах 1С выдерживается строгий методологический подход, то в изменениях к ним также следует придерживаться строгой регламентации тех методологических установок, в основе которых положены действующие законодательные, нормативные, инструктивные и методические документы по ведению учета.
Методологические решения, заимствованные из действующих регламентирующих документов не излагаются. На них делается ссылка.
Описание методологических решений выполняется в виде текста или таблицы, с указанием краткого содержания каждого решения, его обоснования и ссылки на соответствующий директивный или методологический материал.
Методологические решения не являются описанием алгоритма задач. Они представляют собой описание задач с позиций методологии учета, раскрывают идею изменений.
В разделе должен быть отражен еще один аспект привязки. При проведении обследования учетного процесса предприятия (организации) могут быть выявлены необоснованные отклонения от регламентированных положений учета, предусмотренных в программах 1С. Это может мешать проведению привязки, а в дальнейшем и внедрения. Следует указать сущность отклонений и обязательства заказчика по их устранению.
Функциональные спецификации и описание алгоритма Раздел должен включать подробное описание изменений в программе 1С. Описание должно быть приведено в такой форме, чтобы его понял заказчик, не искушенный в тонкостях программы 1С. Утверждая техническое задание, заказчик подписывается тем самым под изменениями, соглашаясь с ними. Здесь имеет место не только формальная сторона дела. Вникая в суть изменений, заказчик Дополнительно страхует исполнителя от возможных ошибок. Основным правилом при написании этого раздела является акцентирование, выпячивание тех аспектов, которые связаны с ломкой действующих на предприятии положений учета.
Одновременно, содержание раздела должно быть достаточным для специалистов при переработке или доработке задач.
Раздел может включать следующие основные спецификации:
· описание плана счетов
· описание справочников
· описание субконто
· описание документов
· описание отчетов
· параметры адаптации
На каждую спецификацию открывается отдельный подраздел.
Описание плана счетов.
Появление новых синтетических счетов (в сравнении с типовой конфигурацией) происходит крайне редко. Это может быть связано с отраслевыми особенностями и регулируется инструкциями. Что же касается появления новых субсчетов, то это наблюдается значительно чаще и связано с необходимостью аккумулирования хозяйственных операций определенного вида. Например, для сельскохозяйственного предприятия счет 20 Основное производство, как минимум, имеет три субсчета Растениеводство, Животноводство, Промышленное производство.
Для предприятий (организаций) со значительными отклонениями от типовой конфигурации приводится полный план счетов. Указываются наименования счетов и их свойства: признак ведения валютного учета, признак ведения количественного учета, признак забалансового счета, признак активный-пассивный.
Обязательно перечисляются счета, субсчета, которые увязаны с формированием отчетности и подлежат обязательному применению.
Для предприятий, где действующий план счетов мало чем отличается от принятого в типовой конфигурации, следует привести фрагмент плана счетов, по которому имеется расхождение. В любом случае, следует перечислить программы, которые предстоит корректировать в связи с изменением плана счетов. Например,
документы, где производится генерация проводок, а также формы отчетности.
По вновь введенным счетам обязательно приводится возможная корреспонденция.
По счетам типовой конфигурации, которые используются на предприятии, пояснения не приводятся.
В подразделе следует описать изменения в системе аналитического учета.
На этапе обследования устанавливается соответствие действующей на предприятии системы аналитического учета, предусмотренной в типовой конфигурации. Известно, что настройку аналитического учета типовой конфигурации рекомендуется сохранять, так как она используется при генерации проводок в документах и в алгоритмах форм отчетности. Конечно, следует добиваться минимально возможных изменений настройки, они могут повлечь увеличение трудоемкости и сложности привязки.
В подразделе технического задания следует привести структуру аналитических разрезов по тем счетам, где имеют место отклонения от типовой конфигурации. Это относится и к субконто типа Перечисление. В отдельный фрагмент целесообразно выделить перечень программ (документы, формы отчетности), которые подлежат корректировке в связи с изменением системы аналитического учета.
Изменения по системе аналитического учета могут быть оформлены в виде таблицы, где на одной ее стороне приводится перечень счетов, а на другой стороне - наименования аналитических разрезов.
Описание справочников.
Здесь приводится информация о вновь введенных справочниках или о справочниках типовой конфигурации с измененными свойствами. Указывается, какого рода информация содержится в справочнике, в каких документах он используется. Если список справочника многоуровневый, указывается назначение групп, а где это необходимо, приводится полный список групп.
По справочникам приводятся основные свойства:
· идентификатор,
· комментарии,
· длина кода и наименования,
· подчиненность,
· количество уровней,
· серии кодов,
· тип кода.
В тех случаях, когда список справочника необходим для понимания всей задачи, он приводится полностью.
По справочнику приводится дополнительная информация об элементах в виде списка реквизитов и их основных свойств:
· наименование,
· идентификатор,
· периодический,
· тип значения,
· длина.
По каждому реквизиту указывается, для какой цели он используется и каким образом заполняется. При описании важно четко разделить информацию на две части: для заказчика и разработчика. Если справочник используется для организации аналитического учета, целесообразно указать конкретные счета, использующие его как субконто.
Описание субконто.
Необходимая информация об организации аналитического учета приводится в подразделе План счетов. В данном подразделе приводятся специальные сведения о свойствах вида субконто, необходимые для разработчика. Для заказчика этот подраздел смысловой нагрузки не несет.
Описание документов.
Новые документы создаются в тех случаях, когда появилась необходимость ввода и печати первичных документов, или когда
требуется автоматизировать формирование проводок. Нередко имеют место обе предпосылки одновременно. Документы могут являться аналогами бумажных документов, но могут представлять собой программы для решения определенных задач.
Описание документа целесообразно начинать с изложения его функционального назначения: состав функций, выполняемых данным документом, перечень решаемых им функциональных и технологических задач, цель создания, укрупненный состав вводимых и расчетных показателей, состав формируемых проводок, закрепленные элементы проводок и соответствующие им значения счетов и аналитических счетов, информационная взаимосвязь с другими задачами, периодичность решения задачи. Функциональное назначение документа можно оформлять в виде таблицы со следующими реквизитами:
· наименование функциональной задачи
· назначение
· функциональное содержание
· периодичность решения
· дополнительные сведения
В дополнительных сведениях приводится краткая характеристика документа (ограничения на возможность применения, условия его реализации, данные, влияющие на его использование и т. п.).
Приведенное описание служит обобщенным алгоритмом и не подменяет собственно алгоритм. Он скорее ориентирован на учетных работников заказчика и дает представление о содержании доработок.
Затем приводится информация, вводимая в документ, диалог ввода. Приводится описание диалога и внешний вид диалога (форма). В форме диалога выделяются шапка и табличная часть документа. Форма диалога должна соответствовать экранному отображению. Проектируется размещение реквизитов на шаблоне экрана, приводятся наименования реквизитов и их идентификаторы. Идентификаторы необходимы для увязки описания диалога с общим описанием алгоритма. Описание диалога приводится в виде таблицы, включающей реквизиты:
· наименование элемента диалога
· порядок обхода элементов
· пояснение по вводу реквизитов.
Затем описываются свойства всех реквизитов документа. В описании целесообразно выделять два раздела: шапка и таблица. Приводятся реквизиты диалога, реквизиты справочников, расчетные реквизиты. Описание можно представить в виде таблицы со следующими реквизитами:
· наименование реквизита
· идентификатор
· тип значения
· длина
· точность
· пояснение
В пояснении указывается порядок формирования значения реквизита (вводимый, справочный, расчетный) и другие сведения.
За таблицей можно расположить описание алгоритма. Алгоритм решения задачи можно приводить по следующей схеме: используемая информация - результаты решения - алгоритм формирования - выходные документы.
В составе используемой информации перечисляются данные диалога, реквизиты справочников, промежуточные расчетные реквизиты.
При изложении алгоритма решения следует приводить:
· описание логики решения задачи и способа формирования результатов решения с указанием последовательности этапов счета;
· расчетные и логические формулы, используемые в алгоритме;
· указания о точности вычислений;
· соотношения, необходимые для контроля достоверности вычислений;
· указания о порядке расположения строк или значений в документе.
Соотношения для контроля вычислений на отдельных этапах выполнения алгоритма приводятся в виде равенств и неравенств. При этом указываются контрольные соотношения, позволяющие выявить допущенные в процессе счета ошибки и принять решения о необходимости отклонений от нормального процесса вычислений.
Описание алгоритма решения задачи должно содержать все варианты ее решения и ситуации, которые могут возникнуть в процессе решения по данным вариантам, включая возможные отклонения от нормального хода решения задачи.
Для описания алгоритма используются все необходимые идентификаторы из таблицы описания свойств реквизитов документа. Алгоритм можно представить в табличной форме. В таблице Алгоритм расчетов приводится порядок формирования реквизитов. Таблица может включать реквизиты:
· наименование формируемого реквизита
· идентификатор формируемого реквизита
· идентификаторы исходных реквизитов
· порядок расчета реквизита
· дополнительные пояснения
Порядок расчета может включать не только формулу, но и наименование бухгалтерских итогов, например, По значению Х обороты по кредиту с начала года.
Отдельную таблицу рекомендуется составлять для описания схемы формирования проводок. В таблице приводятся реквизиты проводок и порядок их формирования. Применяемые в таблице идентификаторы реквизитов должны соответствовать реквизитам, приведенным в таблице описания свойств реквизитов всего документа.
Приводится описание порядка формирования печатной формы документа. Для этого можно использовать две таблицы. В первой таблице Формирование ведомости приводятся реквизиты ведомости и соответствующие им реквизиты документа. По реквизитам ведомости указывается длина и точность. Вторая таблица представляет собой печатную форму ведомости (документа).
Завершает алгоритм документа описание его свойств. Описание можно оформить в табличной форме, включив в нее следующие реквизиты:
· идентификатор документа
· комментарий
· журнал
· нумератор
· периодичность
· длина кода
· тип кода
· используемый компонент
Все части описания алгоритма должны быть взаимоувязаны, в них не должно быть повторении. Те части, которые должны быть согласованы с заказчиком, описываются подробно и прозрачно.
Описание отчетов.
В процессе привязки программ 1С может возникнуть необходимость получения дополнительных отчетных документов. В этом случае информация, накопленная в системе, используется для обобщения и формирования итоговых результатов в различных разрезах. В данном подразделе приводятся алгоритмы формирования вновь введенных отчетов.
Описание алгоритма открывается наименованием отчета, его назначением, организацией использования отчета заказчиком. Затем приводится таблица, представляющая собственно форму отчета. Целесообразно заполнить форму отчета небольшим контрольным примером, чтобы заказчик ясно представлял содержание и расположение информации в отчете.
Затем приводится описание диалога, при помощи которого, при необходимости, можно организовать ввод каких-либо параметров, влияющих на формирование отчета.
В диалоге обычно указываются следующие параметры отчета:
· период, за который формировать отчет (задается выбором даты начала периода и даты окончания периода или выбором круглого периода);
· счет, по которому формировать ведомость;
· виды субконто, по которым ведется аналитический учет по счету;
· значение субконто
В диалог могут быть включены и другие специальные параметры,* вытекающие из особенностей формирования отчета.
Алгоритм формирования реквизитов отчета можно описать с помощью двух таблиц. В первой таблице описывается порядок формирования реквизитов, независимо от того, в какой строке отчета они отражаются. Например, Сумма за период - обороты по кредиту реквизита Сумма за указанный период. В этой же таблице указываются длина и точность реквизита.
Во второй таблице описывается порядок формирования строк отчета. Для этого предварительно идентифицируются все строки отчета, а в таблице по каждой строке приводится порядок ее формирования. Примерный вид строки:
Итоги по субконто 1. Порядок формирования: Наименование субконто; итоговые данные по значению субконто 1; формируется при изменении субконто 1.
Параметры адаптации.
Параметры адаптации программ 1С размещаются в константах. Информация заносится в константы один раз и затем многократно используется при формировании документов, в расчетах, при построении отчетных форм.
Параметрами адаптации служат также реквизиты диалога ввода документов и диалога настройки отчетов.
Условия эксплуатации В разделе приводятся конкретные задачи, поставленные перед заказчиком и с решением которых создаются условия для нормальной эксплуатации программ 1С. К ним могут быть отнесены:
· обновление технических средств по составу и характеристикам;
· наличие необходимого системного программного обеспечения;
· обслуживание технических средств;
· подготовка персонала.
В дальнейшем, эти условия могут быть использованы при составлении регламентирующих документов по внедрению.
Порядок контроля работоспособности программ и сдача-приемка работ по привязке.
Результаты выполненных работ по привязке должны контролироваться и быть принятыми заказчиком. Контроль и приемка распространяется только на те задачи программы 1С, которые были переработаны или разработаны вновь.
Приемка выполненных работ осуществляется по результатам испытаний на контрольном примере. Контрольный пример должен обеспечить проверку функций задач во всех режимах, а также проверку информационных связей между задачами. Данные контрольного примера должен подготовить заказчик. Специалист проверяет исходные данные, проводит анализ результатов выполнения контрольного примера и исправляет ошибки, допущенные при доработке программ.
В разделе следует привести:
· перечень задач, подлежащих проверке на контрольном примере;
· объем контрольного примера;
· содержание контрольного примера (состав первичных документов, справочники и т. д.);
· выполнение контрольного примера;
· порядок отражения результатов испытаний;
· оформление приемки работ.
Контрольный пример должен охватывать ошибочные ситуации, которые могут возникнуть при эксплуатации программ 1С в результате некорректности исходной информации. Для этого следует использовать искусственно подобранные ошибочные данные для проверки работоспособности программ.
После завершения этапа контроля работы и приемки работ, программы могут быть использованы при внедрении.
Этапы разработки После того, как установлен весь состав доработок, составляется план работ. Целесообразно учетным работникам предварительно рассмотреть его и дать свои замечания и рекомендации. Специально должен быть рассмотрен вопрос очередности внедрения. При наличии значительного количества доработок, может быть установлен порядок, при котором первоочередное внедрение одних задач сочетается с проведением привязки по другим задачам. Таким образом, будет установлена последовательность работ по привязке и внедрению.
При выборе очередности привязки и внедрения следует учитывать актуальные потребности заказчика (объем, качество выполнения работ), подготовленность заказчика к переходу на автоматизированный учет, информационные взаимосвязи задач, трудоемкость внедрения той или иной группы задач, технологию обработки, предусмотренную технической документацией программ 1С.
Несмотря на то, что в описании этого раздела темы привязки и внедрения пересекаются, детально вопросы внедрения не рассмотрены. Техническое задание - основной документ, регламентирующий процесс привязки, проведение внедрения должно сопровождаться иными документами. Это позволит разделить различные, по существу, работы по привязке и внедрению и более формально подойти к каждой из них.
В этом же разделе должна быть предусмотрена возможность уточнения и дополнения технического задания в ходе разработки по согласованию между заказчиком и исполнителем. Дополнения оформляются в установленном порядке и являются неотъемлемой частью технического задания.
Этапы работ оформляются в виде таблицы и включают реквизиты:
· Наименование этапа
· Срок выполнения
· Наименование документа, завершающего этап

Психология клиента и как с ней бороться

Основными задачами услуг является поддержание в работоспособном состоянии компьютерной техники, локальной компьютерной сети и программного обеспечения предприятия-клиента, небольшая доработка прикладного программного обеспечения, установленного на предприятии и консультации/обучение персонала клиента.
Вот типичная ситуация. Клиент – небольшая компания, имеющая в своем распоряжении 4-5 компьютеров, включенных в локальную сеть, выделенного сервера нет (его роль выполняет один из компьютеров) и пару принтеров. На компьютерах установлена сетевая версия складской/бухгалтерской программы. Поскольку клиент торгует со склада не только оптом, но и в розницу, с программой идет довольно интенсивная работа. Завершаем работу по установке и настройке программного обеспечения, запускаем в работу всю систему, немножко обучаем персонал. Поскольку до нашего участия компания уже использовала локальные версии тех же программ, особых усилий на обучение не требуется. На этом наше участие во внедрении заканчивается. Завершаем расчеты с клиентом и интересуемся, не хочет ли он заключить с нами договор на абонементное обслуживание своей системы. Мы знаем, что такое обслуживание, может быть и в небольшом объеме, но обязательно нужно, поскольку своего специалиста ни по железу, ни по программному обеспечению у клиента нет, а квалификация персонала во всем, что непосредственно не связано с бухгалтерией, далеко не самого высокого уровня (во всяком случае, подключение отвалившегося сетевого принтера выливается в неразрешимую проблему даже при подробных инструкциях по телефону). Наше предложение с финансовой точки зрения, как нам кажется, весьма привлекательно и сводится примерно к следующему: ежемесячно клиент платит нам 100 долларов и имеет право за эти деньги вызвать нашего специалиста к себе на объект до 5 раз в месяц. Специалист обязан прибыть к клиенту не позднее трех часов после вызова. Общее время работы специалиста у клиента не должно превышать 10 часов (то есть, 5 вызовов по два часа или в любых других комбинациях). Это в ДВА С ПОЛОВИНОЙ РАЗА дешевле, чем просто почасовая работа нашего специалиста (часовая ставка 25 долларов). Единственное, что мы хотим взамен – это выплату ста долларов абонементной платы ежемесячно, вне зависимости от того, понадобилась ли наша помощь клиенту в текущем месяце или не понадобилась. Кстати, если клиенту потребуется дополнительные часы работы наших специалистов, сверх предусмотренных договором лимитов, то мы не бросим клиента, а сделаем все от нас зависящее, чтобы его система работала, и при этом возьмем дополнительную оплату по льготному почасовому тарифу (15 долларов в час вместо 25) – это тоже предусматривается договором. На наш взгляд, условия договора со всех сторон выгодные для клиента и совершенно невыгодные нашей компании (вернее нам они тоже выгодны, когда количество клиентов, обслуживаемых по подобным договорам,  переваливает за десяток).
Как же реагирует на такое предложение клиент? Сначала тот, кто ведет переговоры со стороны клиента (директор или чаще главный бухгалтер) с удивлением вопрошают: «А что, это все еще и обслуживать надо?!». Работают они с вычислительной техникой не первый день и прекрасно знают, что «…это все еще и обслуживать…» обязательно надо. Просто сделав вид, что это им неизвестно, они получают возможность при первой же неисправности или просто при ошибке пользователя, позвонить нам и дико возопить, что «…вот вы тут у нас что-то сделали, а теперь все не работает…». И это не из-за незнания, а из острого желания получить обслуживание своей системы, к которой мы имели несчастье приложить руки, навечно и бесплатно. Ну с этим вопросом обычно удается разобраться быстро, дав клиенту понять, что бесплатно он больше от нас ничего не получит, кроме кратких телефонных консультаций и гарантийного ремонта компьютеров и сетевого оборудования (что и было предусмотрено договором). А дальше опять плавно переходим к абонементному договору, объясняя, что это именно то, что им надо, причем достаточно дешево. Вот тут то и начинается! Два ключевых вопроса. Первый: «…а за что это мы должны Вам платить, если у нас за месяц ничего не сломается и мы Вас вызывать не будем?» и второй: «…а откуда мы знаем, что вы не будете просто сидеть тут у нас и делать вид, что работаете, просто накручивая на счетчик?». Начинаем дискуссию по первому вопросу, объясняем, что деньги берем за то, что мы всегда «на низком старте», готовые гарантировано быстро к ним приехать в случае каких либо неприятностей, в то время как обычные вызовы обслуживаются нами по возможности, как правило, в течение двух-трех суток с момента вызова. Объясняем, что для работы с абонементными клиентами нам нужно содержать кроме технических специалистов еще и склад запчастей и диспетчерскую службу. Да и технических специалистов надо больше, чтобы всегда был хотя бы один свободный для осуществления экстренного вызова. Пускаемся в пространные объяснения самого понятия «абонементное обслуживание», проводим аналоги с бытовой техникой, автосервисом и т.п. В ответ обычно заявляют, что им проще нанять себе сотрудника… Начинаются расчеты затрат на сотрудника и расходов на оплату абонементного договора и сравнение плюсов и минусов того и другого варианта. В итоге наемный сотрудник (равноценный по широте квалификации и к тому же никогда не болеющий и не ходящий в отпуск) проигрывает и по затратам и по плюсам и минусам. Теперь переходим ко второму вопросу. Это самое сложное. Кроме рекомендаций других наших клиентов и голословных заявлений о том, что нам самим не выгодно, чтобы наш человек сидел у клиента и «наматывал» часы, мы никаких аргументов привести больше не можем. Но, в конце концов, клиент великодушно снисходит к тому, чтобы нам поверить. Дальше обсуждаем разные детали. Переговоры прерываются, клиент просит тайм аут, чтобы подумать.
Через пару дней клиент звонит и радостно сообщает, что они готовы заключить договор, все условия их удовлетворяют, только пусть при тех же условиях цена будет не 100 а 60, а лучше 50 долларов – большего они не могут себе позволить. Все. Клиент потерян. Дальнейшие переговоры бессмысленны. Налицо явная попытка получить бесплатный пряник. И это при том, что фирма-клиент, хоть и небольшая, однако, ее месячный оборот переваливает за несколько сот тысяч долларов и при остановке или сбое компьютерной системы убытки могут исчисляться десятками тысяч долларов. И при всем при этом острое желание сэкономить 50 долларов в месяц. Просто абсурд.
Самое забавное в этой ситуации, что весьма вероятно, что работать с этим клиентом мы все-таки будем. Только клиенту это обойдется дороже в финансовом смысле, а нам в смысле моральном. Через пару месяцев у нас в офисе раздастся телефонный звонок и разъяренный главный бухгалтер этой самой фирмы надрывно начнет ту же песню о том, что «…вот вы нам тут плохо сеть сделали и у нас ничего теперь не работает…» и «…чтобы срочно приезжали все исправляли, а то…» (дальше следует список ожидающих нас неприятностей). И это после двух месяцев нормальной работы всего, «что мы там сделали». Наши разговоры о том, что любая компьютерная система требует регулярного обслуживания напрочь забыты: свои грехи нужно спихнуть на кого-то. Начинаем разбираться (пока по телефону). Сначала спрашиваем, а работало ли «все, что мы там сделали» до сегодняшнего дня. Клиент быстро соображает, что допустил ошибку и заявляет, что, конечно же, ничего не работало, но им не особо и нужно было, поэтому они и не звонили. Начинаем крутить этот вопрос и так и этак, и если все-таки здравый смысл возобладал, то разговор переходит в нормальное русло, т.е. договариваемся с клиентом, о том, чем мы сможем ему помочь и сколько это ему будет стоить (в большинстве случаев требуется просто восстановить разрушенные неграмотными пользователями настройки сетевых протоколов и т.п.). Если же клиент невразумляем и твердо задумал вывернуть нас наизнанку, то ему задается простой вопрос: «А у Вас на компьютерах Windows лицензионный?». Windows у них  нелицензионный, но суть не в этом. Поняв, что дальше мы с ними объясняться не собираемся, клиент либо просто начинает угрожать (варианты разные: бандиты, арбитражный суд, жалоба в налоговую инспекцию и т.п.), либо поняв, что наездами от нас ничего не добиться, все же переходит к конструктивным переговорам. Вариант с угрозами здесь рассматривать не будем – эти проблемы каждый решает по-своему. Ну а в случае достижения консенсуса, мы договариваемся о выезде к клиенту наших специалистов (разумеется, за нормальную почасовую оплату) и действительно стараемся прислать к нему людей побыстрее, чтобы он понял преимущества абонемента. Самое обидное для клиента (хотя он этого и не знает), это то, что если бы он позвонил нам и не скандалил, не качал права (а качать права нет даже формального повода – гарантийный срок дается только на компьютеры и сетевое оборудование, а с ним все в порядке), а просто попросил помощи, то мы бы обязательно ему помогли, и, вероятно, даже дали бы скидку. Когда проблема решена, можно опять вернуться к вопросу об абонементном договоре. Иногда это срабатывает с первого раза, иногда со второго или третьего. Иногда вообще не срабатывает, особенно когда на данном предприятии подвизается какой-нибудь отрок с косичкой и немытыми волосами, изображающий из себя асса компьютерного дела. В послекризисные времена с такими личностями приходится сталкиваться достаточно часто, поэтому следует посвятить несколько строк их общему описанию, чтобы в случае необходимости Вы легко смогли опознать такой экземпляр. Высшего и даже среднего технического образования они, как правило, не имеют. Зато часами сидят в Интернете и участвуют во многочисленных конференциях, засоряя их полнейшей чепухой. Их лексикон изобилует массой специальных терминов, почерпнутых их околокомпьютерной литературы и интернетовских чатов. На их личных компьютерах установлены все существующие операционные системы. И конечно они преисполнены собственного величия. Однако, если поинтересоваться у такого существа, что такое алгоритм Лемпеля-Зива-Уэлча, то  последует немая сцена из «Ревизора» Гоголя. Они с одинаковым успехом могут пытаться сжать архиватором файл, расположенный на диске, обработанном Drive Space-ом и отбраковать видеоадаптер с 2Мб видеопамятью только потому, что он не желает работать с разрешением 1024х768 и 32 разрядным цветом. Но… у них у всех есть одно существенное преимущество: их можно нанять за 50 баксов в месяц. Правда, почему-то никому из руководства предприятия не приходит в голову обратить внимание на то, что за свои 50 баксов такой субьект будет появляться на работе не более одного раза в неделю, да и то -  на пол дня. А когда случится аварийная ситуация, искать его будут всей конторой и найдут только через пару дней. Да и техника и программное обеспечение, которые он обслуживает почему-то станут доставлять персоналу предприятия массу неприятностей. Но, несмотря на все это, магическая сумма в 50 долларов делает свое черное дело. Конечно, после крупного прокола с серьезными финансовыми потерями (а такой прокол рано или поздно обязательно случится) сего отрока погонят взашей, но его место займет такой же точно субъект. И только после того, как и этот т.н. «сисадмин» будет с позором изгнан, клиент может обратить свои взоры в нашу сторону. Но и в этом случае клиента ожидают дополнительные финансове потери. Мы ни в коем случае не возьмем на обслуживание предприятие в том виде, в котором его оставили эти горе-специалисты. Сначала нужно обследовать технику и софт, потом наладить то, что они разрушили. Все это стоит клиенту денег, а он их платить очень не хочет. Но и мы не можем взять на себя обязательства (довольно жесткие) по обслуживанию предприятия, если оно останется в том же виде, до которого его довели. Снова складывается ситуация, которую мы уже проходили. И начинается второй круг.
Так в чем же причина? Почему руководители предприятий, которым совершенно очевидно требуется партнер, который возьмет на себя заботы об их технике и программном обеспечении не в состоянии принять правильное решение? Ведь ситуация может быть просто экономически просчитана.
Оставим в стороне предприятия, которым действительно требуется постоянно присутствующий свой сотрудник. Обычно это предприятия с большим количеством (больше 20) разномастных рабочих станций, несколькими серверами, изобилующее принтерами и… с крайне неквалифицированным (в смысле обращения с вычислительной техникой) персоналом. Внедрив на таком предприятии систему мы сами обычно рекомендуем им нанять себе сотрудника, поскольку взяв такое предприятие на абонементное обслуживание мы просто будем вынуждены отрядить кого-то из своих специалистов для постоянного пребывания у этого клиента (а он естественно за такое количество часов работы платить не желает). Мы не только рекомендуем нанять сотрудника, но и сообщаем руководству предприятия-клиента те квалификационные требования, которым должен отвечать данный сотрудник и примерную величину оклада, соответствующую этим квалификационным требованиям. Ведь мы лучше, чем клиент знаем рынок труда в этой области. Несмотря на это в большинстве случаев все развивается по описанному выше сценарию: нанимается копеечный «крутой» специалист, который за несколько месяцев приводит компьютерную систему предприятия в неработоспособное состояние… а затем следуют телефонные звонки нам.
Так в чем же причина? Почему предприятие, оборот которого составляет несколько сотен тысяч (а зачастую и несколько миллионов) долларов в месяц не может нанять себе специалиста с окладом 400-600 долларов или заключить с нами договор на обслуживание на 100-300 долларов в месяц? Почему максимальная сумма, которую предприятие готово потратить на это не превышает 50 долларов? Дело в руководителе. Причем, практически в 100 процентах случаев речь идет о руководителе самого высшего звена: генеральном директоре, исполнительном директоре и т.п. Решение тратить или не тратить и, если тратить, то, сколько тратить, принимает не тот, кто работает с системой. Обычно, непосредственно за работу компьютерной системы отвечает главный бухгалтер предприятия. Он же пользуется теми благами, которые использование этой системы дает предприятию. И, как правило, главный бухгалтер, понимает, что нужно, чтобы эту систему эксплуатировать. Другими словами, имей мы дело только с главным бухгалтером, все было бы прекрасно: предприятие было бы у нас на абонементном обслуживании или там работал бы свой грамотный специалист. Увы, решения принимает другой человек. И вот здесь самое любопытное. Из опыта общения с такими прижимистыми руководителями я вынес твердое убеждение: они четко делятся на две категории. Первая – это та, где руководитель прекрасно понимает, что то, что ему предлагают, это нужно его предприятию, понимает, что это экономически оправдано, но… он не может и не хочет так вот сразу сдаваться. Он будет торговаться. Причем торговаться он будет до тех пор, пока он не сможет сказать себе: «Да, я молодец. Вот как я опустил этих ребят – почти задаром работать будут». Не понимая экономических оснований наших, с его точки зрения невыгодных нам, но выгодных ему, предложений, он решает, что его предприятие почему-то так нам нужно, что мы прямо из кожи вон лезем, чтобы взять его на абонементное обслуживание. А раз так, значит можно торговаться и сбивать цену в два, три и т.д. раза. На мой взгляд, такое поведение можно объяснить только одним: очень большой процент руководителей (а они же обычно являются и владельцами) мелких и средних предприятий выросли на обычной толкучке, на челночном бизнесе и т.п. Образование и некоторый опыт работы в доперестроечный период позволяют таким руководителям понять необходимость обслуживания компьютерной системы их предприятия, но рыночные привычки все равно берут верх. Страсть к сбиванию цены у них уже в крови и торгуются они до посинения. Вторая категория руководителей – это люди, которые считают, что все всегда их обманывают или пытаются обмануть. Обычно это бывшие партийные, профсоюзные и прочие функционеры. Высшего образования они не имеют. За плечами у них длительная практика интриг и подсиживания, но абсолютно никакого понимания, что такое компьютеры и зачем они вообще нужны (кроме компьютерных игр). Компьютерная система у них на предприятии внедряется только потому, что сейчас все так делают (да и главбух давно просит…). На рабочем столе у таких руководителей обязательно есть компьютер (престиж!), но где расположена кнопка включения знает далеко не каждый из них. Их психология проста как грабли. Пятьдесят долларов – это та сумма на которую они могут позволить обмануть себя. Но ни центом больше. Они готовы будут заплатить больше только в том случае, если после длительных поисков не найдут никого, кто бы согласился на эту цену (качество услуг в расчет не принимается – оценить его они просто не могут).
Вообще, разговоры с руководством предприятия-клиента – это тема для большой статьи или даже отдельной книги. Иногда я просто не могу понять, действительно ли директор, с которым ведутся переговоры глуп, или он просто искусно притворяется идиотом. Возьмем простой пример. Кажется, всем давно известно, что гарантия на изделие означает только то, что в период гарантийного срока это изделие поставщик обязан бесплатно отремонтировать или заменить в случае выхода его из строя. И действительно, все это понимают, пока дело касается автомобиля, холодильника, музыкального центра и т.п. Но, как только речь заходит о компьютерах, эти знания сразу улетучиваются из головы клиентов. Почему-то они пребывают в твердой уверенности, что «гарантийные обязательства» на поставляемую технику, смонтированную сеть и т.п. означают, что эти изделия не могут, ну просто не имеют права, сломаться в период действия гарантийного срока! Вы не представляете, каких усилий стоит убедить клиента (руководителя), что это не так. Но даже, если его все-таки удалось убедить – это еще не победа. Не дай Бог, что-то действительно выйдет из строя. Претензии будут выставляться не на тему бесплатного ремонта, а на тему покрытия убытков, вызванных поломкой оборудования, даже в случае, если убытков фактически не было. В такой ситуации спасательной палочкой является договор на поставку оборудования с прописанными в нем обязательствами поставщика (гарантийный ремонт, гарантийный срок) и четкой росписью, за что и в каком случае поставщик несет материальную ответственность.
Наглядным примером вышесказанному может послужить тот факт, что из всех клиентов нашей фирмы, только один имеет в горячем резерве сервер. Да и то этот резервный сервер был установлен только после того, как старый единственный сервер «упал» и его восстановление заняло целый рабочий день, что вылилось в несколько  тысяч долларов убытка для клиента. Этот клиент был у нас на абонементном обслуживании, и нас спасло только то, что в дирекции предприятия-клиента имелась наша, соответствующим образом зарегистрированная, докладная записка с описанием возможности подобной аварийной ситуации и рекомендацией немедленной установки резервного сервера.
Теперь о программном обеспечении, в частности о ПО 1С:Предприятие. Здесь также имеются свои особенности. Чаще всего неприятности возникают не со специально написанными под клиента «настройками», а с типовыми конфигурациями, которые устанавливаются клиенту без внесения каких бы то ни было изменений. В случае написания индивидуальной настройки все обстоит достаточно просто: у нас есть индульгенция под названием «Акт о приемке работ». Если клиент подписал «Акт» - значит его все устраивает (конечно, если в договоре на разработку не оговорено иное). Все выявленные в последующей эксплуатации ошибки и недоработки исправляются нами либо бесплатно (если это действительно наша ошибка), либо за соответствующую оплату. Но в любом случае формально мы не обязаны это делать. В случае же типовых конфигураций, обычно конфликт возникает на почве того, что клиент не находит в конфигурации того, что ожидал там найти. Может быть, этого действительно там нет, хотя чаще случается, так, что клиент, просто не прочитав ужасно толстые книжки с описанием конфигурации, с помощью наезда на нас пытается получить бесплатное обучение или мелкие доработки. В такой ситуации от нас требуется особое упорство. Поскольку лицензионного соглашения на покупку ПО фирмы «1С» в прилагаемых к коробочкам документах не существует, то нам остается только твердо стоять на том, что «…программа полностью соответствует прилагаемой документации…». Хорошо если это действительно так. В противном случае приходится бесплатно исправлять ошибки в типовых конфигурациях или возвращать клиенту деньги и забирать коробочку. Такое случается не часто, но все же случается. Обычно, подобная ситуация возникает, когда будущие пользователи ПО 1С:Предприятие почему-то решили, что купив данный продукт, они избавят себя от необходимости вводить накладные и формировать счета, вбивать данные о сотрудниках и делать сложные проводки. Они мечтают о том, что квартальный баланс будет формироваться сам по себе одним щелчком мыши. Ясно, что такие представления об использовании бухгалтерского ПО произрастают на почве компьютерной безграмотности значительной части потенциальных пользователей и руководства предприятий. И, кроме того, они обильно подпитываются различными рекламными публикациями. Что ж, это, конечно, все преодолимо, но… стоит значительных усилий, нервов и денег.
Существует категория руководителей с которыми практически невозможно вести какие бы то ни было дела. Это – бывшие программисты. Они давно ушили в бизнес, превратились в администраторов (часто очень неплохих администраторов). Иногда они находят время почитать различные журнальчики по компьютерной тематике. Иногда они даже пытаются что-то запрограммировать на Access. И они считают, что уж в чем, в чем, а в компьютерах и в программном обеспечении они разбираются гораздо лучше, чем наши специалисты. Встретив такого руководителя Вы можете твердо быть уверены - работать они Вам не дадут. И денег не заплатят. Есть только один метод, который можно попробовать для борьбы с ними. Вероятность успеха – пятьдесят на пятьдесят. Нужно просто разговорить такого руководителя на техническую компьютерную тему и крепко посадить его в лужу. Если руководитель нормальный, здравомыслящий человек, то скорее всего он поймет все правильно и дальше уже все будет зависеть от Вашей работы. Если же Вы нарветесь на самодура – прощай клиент. Но жалеть не стоит – как я уже сказал, кроме головной боли, ничего иного Вы там не заработаете.
Есть еще один интересный факт, касающийся непосредственно системы 1С:Франчайзинга. Мы в своей компании всегда старались и стараемся поддерживать квалификацию сотрудников, как тех, которые занимаются прикладным программным обеспечением, так и тех, кто занимается системным ПО и аппаратной частью на достаточно высоком уровне. Такой подход, в общем, затрудняет работу – больше затраты на обучение и повышение квалификации, меньше «вал» выполненных (вернее наполовину выполненных или «криво» выполненных) заказов и т.д. Так вот, в последнее время на удивление легко стало договариваться с клиентами, у которых уже побывали сотрудники других фирм-франчайзи. В первую очередь это касается «кривых» недоделанных сетевых установок, недоустановленных обоновлений и апгрейдов на 2000 год, различных сетевых заморочек и т.п. Это не означает, что у нас все получается с первого раза, и по высшему разряду. Но если мы взялись за какую-то недоделанную другими задачу, то стараемся выполнить ее, во что бы то ни стало. И оплату берем за результат, а не за проведенное у клиента время. В конечном итоге – пополнение количества абонементных клиентов. Наилучшей рекомендацией, как оказалось, является не просто выполненная работа, а выполненная работа, которую не смогли выполнить другие.
Итак, какие же выводы можно сделать из всего сказанного. Главный вывод – у руководства потенциальных клиентов сохраняется «посткризисный» синдром, чему в немалой степени способствует огромный рынок незадействованной рабочей силы в той или иной степени знакомой с компьютером. Кризис сумели пережить только те предприятия, руководители которых вели жесткую финансовую политику, экономили каждую копейку. Продолжают они экономить и сейчас, хотя вполне могут позволить себе расслабиться. Пройдет еще немало времени, пока станет очевидным, что политика жесткой экономии, позволившая пережить кризис, стала теперь тормозом в развитии. Соответствует ситуации и положение внедренческих контор, которым приходится прилагать довольно значительные усилия не на разработку собственно заказа, а на «разработку» руководства предприятия-клиента, т.е. больше внимания уделяется вопросам нахождения и удержания клиента, а не самому внедрению, что естественно сказывается на качестве выполняемых работ. Вероятно, пройдет еще некоторое время, пока сменится поколение руководителей потенциальных заказчиков, а внедренцы найдут оптимальный баланс между маркетинговой деятельностью и техническим уровнем непосредственных исполнителей. Это непременно должно произойти в ближайшие 2-3 года. Если не будет нового кризиса

Методология внедрения пакета программ «1С-Предприятие»

Качество достигается за счет четкого определения бизнес-процессов и бизнес-требований предприятия в самом начале проекта и их последовательного отображения на процессы и базу данных внедряемой Прикладной системы.
В конечном итоге рассматриваемый Подход направлен на минимизацию затрат и времени при обеспечении гарантированного качества. Для этого используется тесная интеграция задач собственно внедрения с задачами управления проектом. Именно хорошая организация и управление проектом при правильной методологии дают гарантию успеха.
Рассматриваемая методология представляет собой адаптацию методов, предлагаемых ведущими консультационными и программными фирмами, применительно к конкретным условиям применения системы 1С: Предприятие. Несмотря на то, что изначально данный метод был разработан для средних и больших проектов, он применим и к сравнительно малым проектам.
В данном документе рассматривается в основном аспект методологии, описывающий структуру и связи задачи выполнения внедренческих работ. Также приводятся краткие сведения по процессам и задачам управления проекта. Организационный аспект, описывающий состав и функции группы внедрения, систему управления проектом, сетевые планы работ будут описаны в последующих документах.
В дальнейшем работы по созданию методического обеспечения проектов внедрения будут продолжены по следующим направлениям:
· разработка методических руководств и документов для практического использования;
· подготовка вариантов методологии для различных групп партнеров;
· разработка, выбор и адаптация программных инструментов для решения задач внедрения и сопровождения.
В целом, методология внедрения должна послужить основой для разработки и внедрения новых стандартов качества деятельности компании «1С».
Потребность в методологии Интересы основных участников проектов внедрения Методология служит для решения задач, которые отражают принципиальные интересы различных участников цепочки «компания - партнер - клиент»:

Участник	Задачи
Компания 1С	Обеспечение качества внедрения и сопровождения
Установление и поддержание стандартов деятельности партнеров
Поддержка развития системы
Улучшение имиджа компании
Партнеры	Методическая поддержка внедрения и сопровождения
Пользователи	Эффективное использование системы
Оптимизация внедрения по времени, затратам и рискам
Эффективное сопровождение

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

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

Область применения Методология и разработанные на ее основе методические материалы могут найти следующее практическое применение.

Сфера применения	Методические материалы
Внедрение и сопровождение	Инструменты внедрения и сопровождения
Руководство по внедрению и сопровождению системы «1С:Предприятие»
Типовые формы документов
Обучение и сертификация партнеров и специалистов	Учебный курс, тема «Методология внедрения и сопровождения системы «1С:Предприятие»
Программа сертификационных экзаменов, раздел «Методология внедрения и сопровождения системы «1С:Предприятие»
Обучение клиентов	Программа обучения, раздел «Методология внедрения и сопровождения системы « 1С:Предприятие»

Партнеры компании Практические цели разработки методологии в наибольшей степени затрагивают партнеров компании «1С». Ниже приводится их краткое описание и типизация.
Уровень сервиса Можно выделить три основных группы партнеров по уровню сервиса и числу клиентов. Как показывает опыт, имеется корреляция между уровнем сервиса и числом аттестованных специалистов. Партнеры каждого последующего уровня оказывают услуги предыдущего.

№ уровня	Сервис	Масштабы деятельности	Требования к специалистам	Услуги
1	Гарантированный сервис	Отдельные внедрения	До 3 аттестованных специалистов	Доставка Установка Начальное обучение Регулярное обновление Технические консультации
2	Индустриальный сервис	Массовое внедрение	Более 3 аттестованных специалистов	Гарантированный сервис + Обследование + Дополнительное обучение + Расширение функциональности + Изменение базы данных + Внедрение + Сопровождение, включая модификации и развитие системы
3	Прикладной сервис (разработка приложений под клиента)	Специальное внедрение	Несколько групп аттестованных специалистов Группа бизнес реинжиниринга бизнес-процессов Группа разработки	Индустриальный сервис + Реинжиниринг бизнес-процессов + Полный цикл разработки (либо кардинальная переработка) с использованием инструментальных средств системы

Дополнительные характеристики партнеров в связи особенностями клиентов представлены в таблице ниже.

№ уровня	Уровень сервиса	Масштаб клиента	Вариант поставки	Требования к квалификации	Организационная структура партнера
1	Гарантированный сервис	Индивидуальный клиент	Базовый Стандартный	Низкие	Специалист по вызову
2	Индустриальный сервис	Уровень отдела	Стандартный Профессиональный	Средние	Специализированное подразделение
3	Прикладной сервис	Уровень предприятия	Профессиональный Комплексный	Высокие	Специализированная фирма

Следует отметить ярко выраженное стремление партнеров к переходу на более высокий уровень. Особенно часто наблюдаются миграции с первого на второй уровень. Партнеры, оказывающие индустриальный сервис, постоянно предпринимают попытки перейти на уровень поставки приложений. Однако зачастую эти попытки оказываются безрезультатными в силу недостаточности потенциала и методической подготовки.
Партнеры уровня индустриального сервиса являются наиболее существенными для обеспечения рыночного успеха системы. Именно с ориентацией на них должна разрабатываться методология внедрения и сопровождения.
Выводы Ниже приводятся выводы, имеющие наиболее существенное значение для разработки методологии внедрения системы 1С:Предприятие.
Цель разработки методологии Методология внедрения и сопровождения должна послужить основой для разработки и поддержания стандартов качества в деятельности партнеров всех типов и уровней.
Методическая база Разработка методологии понимается как адаптация методик, предлагаемых ведущими консультационными и программными фирмами, применительно к конкретным условиям применения системы 1С: Предприятие.
Масштабирование системы Система 1С: Предприятие имеет ярко выраженные уровни масштабов и сложности, отражающиеся в различных вариантах поставки. При разработке методологии ориентиром являются профессиональный и комплексный варианты поставки системы.
Тины партнеров Партнеры уровня индустриального сервиса являются наиболее существенными для обеспечения рыночного успеха системы. По мере развития системы и перехода партнеров на прикладной уровень сервиса значение проработанной методологии будет возрастать.
Дальнейшие работы В дальнейшем работы должны быть продолжены по следующим направлениям:
· разработка методических руководств и документов для практического использования;
· подготовка вариантов методологии для различных групп партнеров;
· разработка, выбор и адаптация программных инструментов для решения задач внедрения и сопровождения.
Общий вывод состоит в наличии четкой корреляции между масштабом и сложностью системы, вариантом поставки и уровнем сервиса партнеров. Соответственно, методология должна поддерживать два типа процессов внедрения: ускоренный и полномасштабный, как это показано ниже.

Масштаб системы	Вариант поставки системы	Уровень сервиса	Вариант процесса внедрения
Уровня отдела	Стандартный Профессиональный	Индустриальный	Ускоренный
Уровня предприятия	Профессиональный Комплексный	Прикладной	Полномасштабный

Выполнение проекта
В данном разделе рассматривается структура задач выполнения работ по проекту внедрения. Приводится краткая характеристика фаз и процессов выполнения проекта.
Фазы выполнения проекта
Проект внедрения разбивается на следующие фазы:

№ фазы	Фаза
01	Постановка задачи
02	Анализ и оценка
03	Техническое проектирование
04	Рабочее проектирование
05	Ввод в эксплуатацию
06	Промышленная эксплуатация

Ниже приводится их краткая характеристика.
Постановка задачи
В данной фазе осуществляется планирование проекта, анализ бизнес-задач организации и оценка возможности выполнения этих задач в условиях ограниченного времени, ресурсов и денежных средств. Акцент делается на создании выполнимого рабочего плана и ориентации на достижение общих целей. Для каждого процесса определяются стратегия, задачи и подходы, обеспечивая основу для создания реалистичного плана проекта.
В этой фазе группа проекта проводит моделирование процессов. Целью является определить бизнес-требования и требования к системе, предложить будущую бизнес-модель с учетом текущей ситуации. Группа проекта изучает финансовые, операционные, технические и административные процессы, добиваясь понимания и согласия с детальными бизнес-требованиями. Четкое понимание этих требовании является критическим фактором успеха проекта.
Анализ и оценка
В этой фазе группа проекта разрабатывает сценарии выявления и реализации бизнес-требований, основанные на результатах предыдущей фазы, которые затем используются для оценки соответствия бизнес-требований и стандартной функциональности внедряемой системы. Выявляются разрывы и разрабатываются соответствующие решения по их устранению.
Разрабатывается программно-техническая архитектура. Документы по архитектуре используются для разработки детального проекта во время фазы технического проектирования.
При необходимости готовятся предложения по разработке/модификации модулей расширения функциональности и интеграции с другими приложениями.
С самого начала большое внимание уделяется тестированию. Группа тестирования разрабатывает модели для тестирования рабочих характеристик новой системы. Эти модели обычно сконцентрированы на критических показателях (время реакции, производительность), связанных с ключевыми бизнес-функциями и операциями.
Техническое проектирование
Целью данной фазы является определение и детальная разработка технических решений, обеспечивающих выполнение бизнес-требований. Для этого группа проекта создает детальные описания решений, основываясь на процессах, построенных на предыдущей фазе.
Для удовлетворения бизнес-требований может потребоваться программирование расширений. Возможные варианты соответствующих решений были выработаны на предыдущей фазе. Группа проекта тщательно исследует эти варианты и выбирает из них наиболее подходящий.
Для эффективного использования внедряемой системы может потребоваться внести изменения в существующие роли и процедуры будущих пользователей. Группа проекта тщательно готовит соответствующие предложения.
В этой фазе разрабатывается программно-техническая архитектура, которая в состоянии поддерживать выбранную конфигурацию прикладной системы и пользовательские расширения. Также рассматриваются будущие потребности компании и оцениваются возможные изменения в архитектуре. Параллельно идет работа по подготовке тестов рабочих характеристик системы.
Как только приняты основные решения, начинает готовиться рабочая документация. Документация уточняется и корректируется по мере движения проекта.
Проектирование бизнес-процессов является повторяющейся процедурой. Задачи, охватывающие как фазу анализа, так и фазу технического проектирования, могут выполняться как отдельная часть проекта. Например, группа проектирования/отображения реализует целостный итерационный процесс, включающий создание модели бизнес-процессов и формулирование детальных требований, вытекающих из этой модели, их отображение на прикладную систему, выявление и документирование разрывов, поиск обходных путей и т.д.
Рабочее проектирование
В этой фазе выполняется программирование и тестирование программного обеспечения, включая модули расширения, программы преобразования данных и интерфейсы. Также проводится тестирование для определения соответствия разработанных решений бизнес-требованиям.
Если настройка, расширения и преобразования не требуются, фаза рабочего проектирования все равно остается важной, потому что в нее включен тест бизнес-системы, который обычно выполняется в среде, максимально приближенной к реальным условиям эксплуатации.
Во время фазы рабочего проектирования группой тестирования рабочих характеристик создаются программы тестирования и выполняются сами тесты. Разработчики создают программные модули и проводят их автономное тестирование, а также тестирование связей. Также проводятся тесты интеграции с внешними приложениями. Результатом является работоспособное протестированное программно-техническое решение.
Ввод в эксплуатацию
Во время данной фазы группа проекта реализует окончательное решение в организации. Все элементы внедрения выполняются совместно для успешного перехода к промышленной эксплуатации. Группа проекта проводит обучение конечных пользователей, в то время как техническая группа конфигурирует среду эксплуатации и преобразует данные. Фаза завершается переходом к промышленной эксплуатации, как только конечные пользователи начинают. выполнять свои должностные обязанности, используя при этом новую систему.
В данной фазе управление изменениями и защита организации от негативного влияния внедрения являются наивысшим приоритетом, требующим тщательной предварительной подготовки и планирования.
Если используется подход к реализации по фазам, фаза ввода в эксплуатацию может состоять из нескольких этапов, когда компоненты/экземпляры прикладной системы внедряются на различных географических площадках и/или в бизнес-единицах в различное время.
Промышленная эксплуатация
Данная фаза является последней фазой внедрения и началом процесса сопровождения системы. Персонал ИТ-подразделений работает в ускоренном режиме, обеспечивая использование системы в регулярном режиме и создавая инфраструктуру сопровождения. В данной фазе проводится сравнение фактических результатов с задачами проекта. Наконец, формулируются возможные направления развития системы в контексте совершенствования бизнеса предприятия.
Процессы проекта
Проект может быть представлен как совокупность следующих взаимосвязанных процессов, протекающих параллельно:

Код процесса	Процесс
БП	Моделирование бизнес-процессов
БТ	Определение бизнес-требований
БО	Отображение бизнес-требований
ТА	Построение программно-технической архитектуры
ГШ	Создание программных модулей
ПД	Преобразование данных
ДО	Документирование
ГС	Тестирование бизнес-системы
ГР	Тестирование рабочих характеристик
ОБ	Освоение и обучение
ПЭ	Переход к промышленной эксплуатации

Каждый процесс соответствует определенному аспекту проекта: бизнес-реинижиниринг, документирование, разработка программного обеспечения, обучение и т.д. Процесс представляет собой цепочку задач, специфических для каждой фазы. Таким образом, получается регулярная декомпозиция проекта в виде матрицы «фаза-процесс», которая позволяет упорядочить рассмотрения и организовать управление проектом в виде совокупности регулярных процедур.
Типичная структура проекта показана на рисунке. Ниже приводится краткая характеристика процессов выполнения проекта. Состав задач и основных результатов для каждого процесса приведен в Приложении 1.

	Фазы и процессы проекта внедрения	Постановка задачи	Анализ и оценка	Техн-кое проект-ние	Рабочее проект-ние	Ввод в экс-цию	Промышленная экс-ция
УП	Управление проектом	=======	=======	=======	=======	=======	=======
БП	Моделирование бизнес-процессов	=====	=	=
БТ	Определение бизнес-требований	===	=======
ВО	Отображение бизнес-требований		=======	==
ТА	Построение технической архитектуры	=====	======	=	=======
ПМ	Создание программных модулей	=	=	======	====
ПД	Преобразование данных	=		======	====
ДО	Документирование	=====	==		====
ТС	Тестирование бизнес-системы	=		====	=======	=
ТР	Тестирование рабочих характеристик	=	==	====	=======
ОБ	Освоение и обучение	=======	=	======	==	==	==
ПЭ	Переход к промышленной эксплуатации		=		==	=======	=======

Моделирование бизнес-процессов
Задачи данного процесса в основном связаны с построением укрупненного (высокоуровневого) описания организации клиента: структуры бизнеса, перспектив развития, основных бизнес-процессов, организационной структуры, системы управления, приоритетов информатизации, иных существенных моментов. По существу, речь идет о построении архитектуры организации клиента.
В рамках процесса моделирования бизнес-процессов также решается важная задача определения укрупненного баланса между доработкой прикладной системы и внесением изменений в организацию и технологию деятельности предприятия клиента.
Определение бизнес-требований
В процессе определения бизнес-требований формулируются потребности поддержки бизнеса, которым должна удовлетворять внедряемая прикладная система. Существенные требования отражаются в т.н. сценариях бизнес-требований, которые описывают источник требований, их обоснование, связь с другими требованиями, способы обеспечения его выполнения и проверки, другие существенные моменты.
Как часть процесса определяются финансовая и операционная структуры предприятия. Дополнительно собирается информация об объемных показателях деятельности, которая позволяет оценить интенсивность и структуру информационных потоков, а также структуру размещения и объемы данных.
Отображение бизнес-требований
В процессе отображения проводится сравнение бизнес-требований со стандартной функциональностью прикладной системы. Главная цель сравнения - выявить разрывы, которые должны быть устранены для достижения максимально возможного соответствия бизнес-требованиям. Основой для проведения работ является описание архитектуры предприятия и сценарии бизнес-требований.
По мере выявления, разрывы между требованиями и функциональностью удаляются с помощью разработки каких-либо обходных путей, включая изменения в бизнес-процессах, изменение структуры базы данных, либо разработку модулей расширения функциональности.
Построение технической архитектуры
Техническая архитектура представляет собой описание принципиальных технических решений, включая прикладное программное обеспечение, аппаратные средства, локальную сеть, системную платформу. В частности, решаются такие важные вопросы, как выбор типа сервера, схема размещения данных, схема управления доступом и разделения данных между различными подразделениями, интерфейсы к внешним приложениям.
Именно на уровне архитектуры производится дальнейшее уточнение требований. Главная цель процесса - адекватное отображение бизнес-требований на уровне технических решений.
Целостная и адекватная архитектура прикладной системы является критическим фактором успеха для любого проекта внедрения. Проект технической архитектуры должен удовлетворять следующим требованиям:
· использование при разработке полных и точных данных;
· согласованность с корпоративным видением бизнеса;
· реалистичность в отношении возможностей предприятия и ограничений используемых технологий.
Первый из перечисленных выше пунктов особенно важен, поскольку архитектурная часть проекта зачастую считается чисто технической, в результате чего возникает риск подгонки бизнес-требований к применяемой технологии. Хорошо управляемый проект разработки архитектуры использует бизнес-требования и их отображение для решения следующих задач:
· выбор оптимальной конфигурации внедряемой системы;
· создание программно-аппаратной инфраструктуры и сети, обеспечивающих работу прикладной системы
· выбор и/или разработка инструментов и процедур, необходимых для управления прикладной системой.
Будучи связанным с другими процессами, процесс построения архитектуры начинается уже на ранних фазах проекта внедрения. Хотя формально процесс действует только во время фаз постановки задачи, анализа и оценки, технического проектирования, документы по архитектуре используются на протяжении всего проекта внедрения. В конечном итоге, именно архитектура является переходным элементом между требованиями бизнеса и конкретными решениями на уровне реализации.
Создание программных модулей
В процессе проектирования и Программирования модулей принимаются решения по разработке дополнительного программного обеспечения (либо модификации существующего) с целью устранения разрывов в функциональности, выявленных в процессе отображения бизнес-требований.
Предлагаемые решения охватывают программные модули (формы интерфейса, отчеты, обработка данных и т.д.), которые должны быть спроектированы, запрограммированы и протестированы до того, как они будут включены в систему.
Основой для подготовки внешних спецификаций модулей, как и всего процесса в целом, служит техническая архитектура и результаты отображения бизнес-требований.
Преобразование данных
В процессе преобразования данных решаются задачи по идентификации, преобразованию и переносу унаследованной информации в базу данных внедряемой прикладной системы. Преобразованные данные используются как во время эксплуатации, так и при тестировании модулей, обучении и приемочном тестировании.
Общая стратегия определяет средства, методы и процедуры преобразования. Отдельно рассматриваются ручные процедуры для отдельных фрагментов данных. Процесс преобразования включает разработку и тестирование необходимых процедур и программ, а также проверку правильности фактически преобразованных данных.
Документирование
Процесс документирования начинается с самого начала проекта. Обязательно документируются и формально утверждаются решения по ключевым вопросам, включая планы и организацию проекта, бизнес-требования, принципиальные технические решения, результаты комплексного и приемочного тестирования, техническое обслуживание, управление системой и работу пользователей.
Полный набор документации включает руководство по управлению системой, руководство пользователя, справочное руководство пользователя, техническое справочное руководство и текст оперативной подсказки. Создание прототипов каждого документа начинается уже на ранних фазах проекта.
Тестирование бизнес-системы
Главной задачей процесса тестирования бизнес-системы является разработка и проведение тестов, результаты которых позволяют объективно оценить степень выполнения бизнес-требований, прежде всего, требований к бизнес-логике, функциональности, пользовательскому интерфейсу, совместной работе с внешними приложениями и пользовательскими расширениями.
Процесс тестирования бизнес-системы обеспечивает формальный интегрированный подход к тестированию. Основным результатом является высококачественная прикладная система, объединяющая стандартные компоненты и пользовательские расширения.
Тестирование рабочих характеристик
Процесс тестирования рабочих характеристик нацелен получение объективного подтверждения требуемых показателей производительности, времени реакции, надежности и других критичных для конкретной ситуации параметров.
Важной задачей данного процесса является использование общей методологии при тестировании различных компонентов, минимизация объемов повторного тестирования, установление связей между показателями тестирования отдельных компонентов и системы в целом.
Эффективность тестирования, и даже сама возможность его проведения, существенно зависит от наличия соответствующих инструментальных средств, позволяющих смоделировать различные ситуации функционирования в реальных условиях. Чаще всего для этих целей может использоваться командный язык интерпретирующего типа (например, командная оболочка операционной системы либо специальный язык для моделирования прикладной системы), позволяющий описывать различные сценарии.
Освоение и обучение
В процессе освоения и обучения достигается главная цель - обеспечение эффективного использования всех возможностей прикладной системы, а также средств управления и обслуживания. Для этого разрабатывается и реализуется программа подготовки менеджеров различного уровня к работе в новых условиях, а также проходит интенсивное обучение администраторов системы, специалистов по техническому обслуживанию и конечных пользователей. При этом важно адаптировать учебные курсы к конкретной ситуации, ориентируясь на ролевые задачи и должностные обязанности персонала, а не на изучение отдельных модулей прикладной системы и выполнение отдельных операций.
Следует проводить четкое различие между теоретическими и практическими занятиями. Теоретические занятия обеспечивают понимание основ и логики функционирования бизнеса в новой информационной среде, в то время как практические занятия направлены на освоение практических навыков в работы информационной системой в реальных условиях.
Составной частью процесса обучения и освоения является выработка рекомендаций по созданию условий эффективной работы персонала в новой среде.
При внедрении информационной системы часто приходится сталкиваться с непониманием и даже прямым противодействием со стороны отдельных групп сотрудников и менеджеров предприятия клиента. Существенным элементом процесса обучения и освоения является продвижение новой концепции деятельности с помощью проведения специальной разъяснительной компании, ориентированной на различные контактные аудитории, способные повлиять на успех проекта.
Переход к промышленной эксплуатации
Процесс перехода к промышленной эксплуатации переводит предприятие и персонал на полномасштабное использование новой информационной системы. Процесс перехода к промышленной эксплуатации включает в себя планирование и обеспечение готовности к эксплуатации, собственно переход к эксплуатации и последующую поддержку.
Переход считается завершенным, когда полностью сформирована база данных, и пользователи начали полностью работать в новой системе. После этого старая система выводится из использования. Как только достигается режим стабильного функционирования, начинается постоянное сопровождение и улучшение системы.
В процессе перехода, а также в начальный период эксплуатации могут готовиться рекомендации по усовершенствованию как отдельных бизнес-процессов, так и функций самой прикладной системы. Основой для этого служат планы и решения руководства предприятия клиента о дальнейшем развитии бизнеса и его информатизации.
Управление проектом
В конечном итоге управление проектом направлено на достижение гарантированного результата при заданных ограничениях на сроки, денежные и трудовые ресурсы. Для этого используется тесная интеграция задач собственно внедрения с задачами управления проектом. Именно хорошая организация и управление проектом является гарантией успеха.
Стадии и этапы управления проектом
С точки зрения управления проект разбивается на ряд стадий -по числу фаз. Все стадии имеют схожую структуру и включают в себя следующие этапы:
Взаимосвязь процессов собственно выполнения работ и процессов управления показана на рисунке. Ниже приводится краткая характеристика этапов. Состав зада

Код этапа	Этап	Когда выполняется
ПП	Планирование проекта	При запуске проекта
ФП	Планирование фазы	В начале каждой фазы проекта
ФК	Контроль фазы	В процессе выполнения каждой фазы проекта
ФЗ	Завершение фазы	При окончании каждой фазы проекта
ПЗ	Завершение проекта	При окончании проекта

ч каждого этапа определяется в описании процессов управления проектом (Приложение 2) и рабочем плане проекта (Приложение 3).
Планирование проекта
На данном этапе основное внимание уделяется решению стратегических задач проекта, включая:
· определение предмета, рамок, целей проекта;
· создание организационной структуры и системы управления проектом;
· ориентацию всех участников проекта;
· распределение ответственности между исполнителем и клиентом;
· обеспечению ресурсами;
· составление бюджета;
· установление сроков для основных работ.
Планирование фазы
Планирование фазы носит более оперативный характер и представляет собой, по сути, адаптацию задач планирования проекта применительно к более детальному уровню отдельной фазы. На этапе планирования фазы при необходимости происходит коррекция планов, включая планы проекта.
На практике планирование проекта и планирование первой фазы часто представляются в виде одного этапа.
Контроль фазы
Процесс контроля протекает параллельно процессу собственно внедрения. Основными задачами этапа является мониторинг хода проекта, подготовка отчетов и оперативное регулирование.
Завершение фазы
На этапе завершения фазы проводятся в основном организационные мероприятия, связанные с подведением итогов и переходом к выполнению следующей фазы. Главной задачей этапа является обеспечение приемки результатов фазы клиентом и подписание соответствующих официальных документов.
Завершение проекта
Состав задач этапа завершения проекта аналогичен этапу завершения фазы. При завершении проекта происходит сдача-приемка всего проекта в целом. Важнейшими задачами данного этапа являются урегулирование всех спорных вопросов и окончательные расчеты.
На практике завершение всего проекта и завершение последней фазы часто представляются в виде одного этапа.
*** Схема «Взаимосвязь процессов выполнения и управления» – не приводится из-за своей бессодержательности.
Процессы управления проектом
Структура задач каждого этапа определяется с помощью следующих процессов управления:

Код процесса	Процесс управления проектом
УО	Контроль и отчетность
УР	Управление работами
УС	Управление ресурсами
УК	Управление качеством
УФ	Управление конфигурацией

Каждый процесс соответствует определенному аспекту управления проектом. Процесс представляет собой цепочку задач, специфических для каждого этапа. Таким образом, получается регулярная декомпозиция системы управления проектом в виде матрицы «этап-процесс», которая позволяет упорядочить рассмотрения и организовать управление проектом в виде совокупности регулярных процедур. Данная декомпозиция представлена на рисунке.
Ниже приводится краткая характеристика процессов управления проектом. Состав задач каждого процесса определяется в описании процессов управления проектом (Приложение 2).
Контроль и отчетность
Задачи данного процесса состоят в мониторинге и оперативном регулировании, направленном на выполнение планов, соблюдение установленного подхода к реализации проекта, разрешение споров, проведение изменений проекта в зависимости от ситуации.
Управление работами
Данный процесс в основном связан с составлением и контролем выполнения рабочего плана и бюджета проекта.
Управление ресурсами
Задачи данного процесса направлены на решение вопросов по обеспечению и эффективному использованию ресурсов, необходимых для успешного выполнения проекта, важнейшим из которых являются люди. Данный этап также тесно связан с созданием инфраструктуры проекта, т.е. организационно-технологического комплекса, в рамках которого развивается проект. Примерами элементов инфраструктуры может служить создание оборудованного участка для проведения тестов, генерации прикладной системы для последующего переноса в подразделения предприятия клиента.
Управление качеством
Задачи данного этапа решаются с целью обеспечить надлежащее качество промежуточных и итоговых результатов проекта. Это достигается за счет соблюдения стандартов и процедур для всех видов деятельности, а также за счет тщательного анализа и оценки выходных результатов каждой фазы.
Управление конфигурацией
Управление конфигурацией имеет своим предметом элементы проекта любой природы, которые создаются и используются в ходе выполнения проекта, а также передаются клиенту. Такими элементами могут быть документы, программы, вычислительное оборудование, обученный персонал и т.д. Управление конфигурацией направлено на поддержку эффективного учета, хранения и использования всех элементов проекта.

	Процессы и этапы управления проектом	План-ние проекта	План-ние фазы	Контроль фазы	Завершение фазы	Завершение проекта
УО	Контроль и отчетность	========	========	========	==	==
УР	Управление работами	======	====	========
УС	Управление ресурсами	========	======	========	====	====
УК	Управление качеством	==	==	========	==	==
УФ	Управление конфигурацией	==	==	========	==	====

Рабочий план проекта
Регулярная декомпозиция задач проекта позволяет построить детальный сетевой график, который отражает взаимосвязи задач. На основе сетевого графика создается рабочий план, представляющий собой структурированный перечень задач, упорядоченный во времени.
Типовой рабочий план представлен в Приложении 3.
Обязательные и дополнительные задачи
Рассматриваемый типовой рабочий план охватывает все ситуации внедрения, включая случай комплексной поставки системы масштаба предприятия с большим объемом разработок. Однако независимо от масштаба и сложности системы можно выделить набор обязательных задач, выполнение которых реально обеспечивает достижение высокого уровня качества.
Следует, отметить, что именно набор обязательных задач устанавливает стандарт качества для реализации проектов внедрения системы «1С: Предприятие».
Выполнение обязательных задач требует от исполнителя значительной методической подготовки и создания у себя продвинутой технологии. Основную часть работ по разработке конкретных методик, форм документов и инструментов внедрения для обязательных задач выполнит компания «1С». Соответствующие результаты будут доступны всем партнерам, что в значительной степени облегчит переход всей партнерской сети на новый уровень обслуживания клиентов.
Документирование результатов
Важнейшим элементом технологии внедрения является документирование основных результатов на всех стадиях проекта. Набор обязательных документов для всех проектов внедрения представлен в рабочем плане. Данные документы служат в конечном итоге достижению одной цели: подтверждению качества конечного результата, понимаемого комплексно:
· соблюдение сроков и ресурсных ограничений;
· обеспечение требуемой функциональности;
· достижение целевых рабочих характеристик (производительности, времени ответа, надежности и т.п.).
Данные документы позволяют объективно оценивать качество деятельности каждого партнера, а также служат конструктивной платформой при разрешении споров с клиентом. Аналогично методическому обеспечению компания «1С» разработает формы всех обязательных документов, которые будут доступны всем партнерам.
События проекта
В рабочем плане представлены основные контрольные точки, соответствующие началу и окончанию фаз и этапов проекта.
Обобщенные процессы
Некоторые задачи выполнения и управления проектом для удобства объединены в типовом плане в обобщенные процессы:

Код процесса	Процесс
ФП-КОР	Провести обзор и ревизию планов
ФК-ИНД	Контролировать выполнение фазы
ФК-РЕЗ	Контролировать не размещенные резервы

Набор задач каждого такого процесса получается в виде объединения однотипных задач, связанных с планированием, контролем и завершением. Дополнительная классификация задач управления по типам показана в описаниях процессов управления проектом (Приложение 2).

Автоматизированные системы. Стадии создания

Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях (далее организациях). Стандарт устанавливает стадии и этапы создания AC, a также содержание работ на каждом этапе.
Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. Стадии и этапы создания АС в общем случае приведены ниже.
1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС
1.2. Формирование требований пользователя к АС
1.3. Оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания)
2. Разработка концепции АС
2.1. Изучение объекта
2.2. Проведение необходимых научно-исследовательских работ
2.3. Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя
2.4. Оформление отчета о выполненной работе
3. Техническое задание
Разработка и утверждение технического задания на создание АС
4. Эскизный проект
4.1 Разработка предварительных проектных решений по системе и ее частям
4.2. Разработка документации на АС и ее части
5. Технический проект
5.1. Разработка проектных решений по системе и ее частям
5.2. Разработка документации на АС и ее части
5.3. Разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку
5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации
6. Рабочая документация
6.1. Разработка рабочей документации на систему и ее части
6.2. Разработка или адаптация программ
7. Ввод в действие
7.1. Подготовка объекта автоматизации к вводу АС в действие
7.2. Подготовка персонала
7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
7.4. Строительно-монтажные работы
7.5. Пусконаладочные работы
7.6. Проведение предварительных испытаний
7.7. Проведение опытной эксплуатации
7.8. Проведение приемочных испытаний
8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными обязательствами
8.2. Послегарантийное обслуживание
Допускается исключать стадию Эскизный проект и отдельные этапы работ на всех стадиях, объединять стадии Технический проект и Рабочая документация в одну стадию Технорабочий проект. В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
На этапе 1.1 в общем случае проводят сбор данных об объекте автоматизации и осуществляемых видах деятельности; оценку качества функционирования объекта и осуществляемых видов деятельности, выявление проблем, решение которых возможно средствами автоматизации; оценку (технико-экономической, социальной и т. п.) целесообразности создания АС.
На этапе 1.2 проводят подготовку исходных данных для формирования требований к АС (характеристика объекта автоматизации, описание требований к системе, ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы); формулировку и оформление требований пользователя к АС.
На этапе 1.3 проводят оформление отчета о выполненных работах на данной стадии и оформление заявки на разработку АС (тактико-технического задания) или другого замещающего ее документа с аналогичным содержанием.
На этапах 2.1 и 2.2 организация-разработчик проводит детальное изучение объекта автоматизации и необходимые научно-исследовательские работы (НИР), связанные с поиском путей и оценкой возможности реализации требований пользователя, оформляют и утверждают отчеты о НИР.
На этапе 2.3 в общем случае проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; сопоставление требований пользователя и характеристик предлагаемой системы и выбор оптимального варианта; определение порядка оценки качества и условий приемки системы; оценку эффектов, получаемых от системы.
На этапе 2.4 подготавливают и оформляют отчет, содержащий описание выполненных работ на стадии, описание и обоснование предлагаемого варианта концепции системы.
На этапе 3.1 проводят разработку, оформление, согласование и утверждение технического задания на АС и, при необходимости, технических заданий на части АС.
На этапе 4.1 определяются функции АС; функции подсистем, их цели и эффекты; состав комплексов задач и отдельных задач; концепции информационной базы, ее укрупненная структура; функции системы управления базой данных; состав вычислительной системы; функции и параметры основных программных средств.
На этапе 5.1 обеспечивают разработку общих решений по системе и ее частям, функционально-алгоритмической структуре системы, по функциям персонала и организационной структуре, по структуре технических средств, по алгоритмам решений задач и применяемым языкам, по организации и ведению информационной базы, системе классификации и кодирования информации, по программному обеспечению.
На этапах 4.2 и 5.2 проводят разработку, оформление, согласование и утверждение документации в объеме, необходимом для описания полной совокупности принятых проектных решений и достаточном для дальнейшего выполнения работ по созданию АС.
На этапе 6.1 осуществляют разработку рабочей документации, одержащей все необходимые и достаточные сведения для
обеспечения выполнения работ по вводу АС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы в соответствии с принятыми проектными решениями, ее оформление, согласование и утверждение.
На этапе 6.2 проводят разработку программ и программных средств системы, выбор, адаптацию и/или привязку приобретаемых программных средств, разработку программной документации.
На этапе 7.1 проводят работы по организационной подготовке объекта автоматизации к вводу АС в действие, в том числе: реализацию проектных решений по организационной структуре АС; обеспечение подразделений объекта управления инструктивно-методическими материалами; внедрение классификаторов информации.
На этапе 7.2 проводят обучение персонала и проверку его способности обеспечить функционирование АС.
На этапе 7.6 осуществляют испытания АС на работоспособность и соответствие техническому заданию в соответствии с программой и методикой предварительных испытаний; устранение неисправностей и внесение изменений в документацию на АС, в том числе эксплуатационную в соответствии с протоколом испытаний; оформление акта о приемке АС в опытную эксплуатацию.
На этапе 7.7 проводят опытную эксплуатацию АС; анализ результатов опытной эксплуатации АС; доработку (при необходимости) программного обеспечения АС; дополнительную наладку (при необходимости) технических средств АС; оформление акта о завершении опытной эксплуатации.
На этапе 7.8 проводят испытание на соответствие техническому заданию в соответствии с программой и методикой приемочных испытаний; анализ результатов испытаний АС и устранение недостатков, выявленных при испытаниях; оформление акта о приемке АС в постоянную эксплуатацию.
На этапе 8.1 осуществляют работы по устранению недостатков, выявленных при эксплуатации АС в течение установленных гарантийных сроков, внесению необходимых изменений в документацию на АС.
На этапе 8.2 осуществляют работы по анализу функционирования системы; выявлению отклонений фактических эксплуатационных характеристик АС от проектных значений; установлению причин этих отклонений; устранению выявленных недостатков и обеспечению стабильности эксплуатационных характеристик АС; внесению необходимых изменений в документацию на АС.
ПЗ.2. РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов
Настоящие методические указания распространяются на автоматизированные системы (АС), используемые в различных сферах деятельности (управление, исследование, проектирование и т.п.), включая их сочетание, и устанавливают требования к содержанию док ументов, разрабатываемых при создании АС.
Содержание документов является общим для всех видов АС и, при необходимости, может дополняться разработчиком документов в зависимости от особенностей создаваемой АС. Допускается включать в документы дополнительные разделы и сведения, объединять и исключать разделы. Содержание каждого документа определяет разработчик в зависимости от объекта проектирования (системы, подсистема и т.д.).
1. Пояснительные записки к эскизному, техническому проектам содержат разделы: общие положения; описание процесса деятельности;
основные технические решения; мероприятия по подготовке объекта автоматизации к вводу системы в действие.
В разделе Общие положения приводят:
• наименование проектируемой АС и наименования документов, их номера и дату утверждения, на основании которых ведут проектирование АС;
• перечень организаций, участвующих в разработке системы, сроки выполнения стадий;
• цели, назначение и области использования АС;
• подтверждение соответствия проектных решений действующим нормам и правилам техники безопасности, пожаро- и взрывобезопасности и т.п.;
• сведения об использованных при проектировании нормативно-технических документах;
• сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта;
• очередность создания системы и объем каждой очереди.
В разделе Описание процесса деятельности
• отражают состав процедур (операций) с учетом обеспечения взаимосвязи и совместимости процессов автоматизированной и неавтоматизированной деятельности;
• формируют требования к организации работ в условиях функционирования АС.
В разделе Основные технические решения приводят:
• решения по структуре системы, подсистем, средствам и способам связи для информационного обмена между компонентами системы, подсистем;
• решения по взаимосвязям АС со смежными системами, обеспечению ее совместимости;
• решения по режимам функционирования, диагностированию работы системы;
• решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку взаимодействия;
• сведения об обеспечении заданных в техническом задании (ТЗ) потребительских характеристик системы (подсистем), определяющих ее качество;
• состав функций, комплексов        задач, реализуемых системой (подсистемой);
• решения по комплексу технических средств, его размещению на объекте;
• решения по составу информации, объему, способам ее организации, видам машинных носителей, входным и выходным документам и сообщениям, последовательности обработки информации и другим компонентам;
• решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций и методам их реализации.
В разделе Мероприятия по подготовке объекта автоматизации к вводу системы в действие приводят:
• мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
• мероприятия по обучению и проверке квалификации персонала;
• мероприятия по созданию необходимых подразделений и рабочих мест;
• мероприятия по изменению объекта автоматизации;
• другие мероприятия, исходящие из специфических особенностей создаваемых АС.
2. Схема функциональной структуры содержит:
• элементы функциональной структуры АС (подсистемы АС);
автоматизированные функции и/или задачи (комплексы задач);
совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком;
• информационные связи между элементами и с внешней средой с кратким указанием содержания сообщений и/или сигналов, передаваемых по связям, и при необходимости, связи других типов (входимости, подчинения и т. д.);
• детализированные схемы частей функциональной структуры (при необходимости).
3. Описание автоматизируемых функций содержит разделы: исходные данные; цели АС и автоматизированные функции; характеристика функциональной структуры; типовые решения (при наличии).
В разделе Исходные данные приводят:
• перечень исходных материалов и документов, использованных при разработке функциональной части проекта АС;
• особенности объекта управления, влияющие на проектные решения по автоматизированным функциям;
• данные о системах управления, взаимосвязанных с разрабатываемой АС, и сведения об информации, которой она должна обмениваться с абонентами и другими системами;
• описание информационной модели объекта вместе с его системой управления.
В разделе Цели АС и автоматизированные функции приводят описание автоматизированных функций, направленных на достижение установленных целей.
Раздел Характеристика функциональной структуры содержит:
• перечень подсистем АС с указанием функций и/или задач, реализуемых в каждой подсистеме;
• описание процесса выполнения функций (при необходимости);
• необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком;
•требования к временному регламенту и характеристикам процесса реализации автоматизированных функций (точности, надежности и т.п.) и решения задач.
В разделе Типовые решения приводят перечень типовых решений с указанием функций, задач, комплексов задач, для выполнения которых они применены.
4. Описание постановки задачи (комплекса задач) содержит разделы: характеристики комплекса задач; выходная информация; входная информация.
В разделе Характеристики комплекса задач приводят:
• назначение комплекса задач;
• перечень объектов (технологических объектов управления, подразделений предприятия и т. п.), при управлении которыми решают комплекс задач;
• периодичность и продолжительность решения;
•условия, при которых прекращается решение комплекса задач автоматизированным способом (при необходимости);
• связи данного комплекса задач с другими комплексами (задачами) АС;
• должности лиц и/или наименования подразделений, определяющих условия и временные характеристики конкретного решения задачи (если они не определены общим алгоритмом функционирования системы);
• распределение действий между персоналом и техническими средствами при различных ситуациях решения комплекса задач.
Раздел Выходная информация содержит:
• перечень и описание выходных сообщений;
• перечень и описание имеющих самостоятельное смысловое значение структурных единиц информации выходных сообщений (показателей, реквизитов и их совокупностей, сигналов управления) или ссылку на документы, содержащие эти данные.
В описании по каждому выходному сообщению следует указывать:
• идентификатор;
• форму представления сообщения (документ, видеокадр, сигнал управления) и требования к ней;
• периодичность выдачи;
• сроки выдачи и допустимое время задержки решения;
• получателей и назначение выходной информации. В описании по каждой структурной единице информации следует указывать:
• наименование;
• идентификатор выходного сообщения, содержащего структурную единицу информации;
• требования к точности и надежности вычисления (при необходимости).
Раздел Входная информация должен содержать:
•перечень и описание входных сообщений (идентификатор, форму представления, сроки и частоту поступления);
•перечень и описание структурных единиц информации входных сообщений или ссылку на документы, содержащие эти данные.
В описании по каждой структурной единице информации входных сообщений следует указывать:
• наименование;
• требуемую точность ее числового значения (при необходимости);
• источник информации (документ, видеокадр, устройство, кодограмма, информационная база на машинных носителях и т. д.);
• идентификатор источника информации.
5. Общее описание системы содержит разделы: назначение системы; описание системы; описание взаимосвязей АС с другими системами; описание подсистем (при необходимости).
В разделе Назначение системы указывают:
• вид деятельности, для автоматизации которой предназначена система;
• перечень объектов автоматизации, на которых используется система;
• перечень функций, реализуемых системой. В разделе Описание системы указывают:
• структуру системы и назначение ее частей;
• сведения об АС в целом и ее частях, необходимые для обеспечения эксплуатации системы;
• описание функционирования системы и ее частей.
В разделе Описание взаимосвязей АС с другими системами указывают:
• перечень систем, с которыми связана данная АС;
• описание связей между системами;
• описание регламента связей;
• описание взаимосвязей АС с подразделениями объекта автоматизации.
В разделе Описание подсистем указывают:
• структуру подсистем и назначение ее частей;
• сведения об подсистемах и их частях, необходимые для обеспечения их функционирования;
• описание функционирования подсистем и их частей.
6. Программа и методика испытаний должна содержать перечни конкретных проверок (решаемых задач), которые следует осуществлять при испытаниях для подтверждения выполнения требований ТЗ, со ссылками на соответствующие методики (разделы методик) испытаний. Перечень проверок, подлежащих включению в программу испытаний, включает:
• соответствие системы ТЗ;
• комплектность системы;
• комплектность и качество документации;
• комплектность, достаточность состава и качество программных средств и программной документации;
• количество и квалификация обслуживающего персонала;
• степень выполнения требований функционального назначения системы;
• контролепригодность системы;
• выполнение требований техники безопасности, противопожарной безопасности, промышленной санитарии, эргономики;
• функционирование системы с применением программных средств.
Программа испытаний содержит разделы: объект испытаний; цель испытаний; общие положения; объем испытаний; условия и порядок проведения испытаний; материально-техническое обеспечение испытаний; метрологическое обеспечение испытаний; отчетность.
В разделе Объект испытаний указывают: полное наименование системы, обозначение; комплектность испытательной системы.
В разделе Цель испытаний указывают конкретные цели и задачи, которые должны быть достигнуты и решены в процессе испытаний.
В разделе Общие положения указывают:
• перечень руководящих документов, на основании которых проводят испытания;
• место и продолжительность испытаний;
• организации, участвующие в испытаниях;
• перечень ранее проведенных испытаний;
• перечень предъявляемых на испытания документов, откорректированных по результатам ранее проведенных испытаний.
В разделе Объем испытаний указывают:
• перечень этапов испытаний и проверок, а также количественные и качественные характеристики, подлежащие оценке;
• последовательность проведения и режимы испытаний;
• требования по испытаниям программных средств;
• перечень работ, проводимых после завершения испытаний, требования к ним, объем и порядок проведения.
В разделе Условия и порядок проведения испытаний указывают:
• условия проведения испытаний;
• условия начала и завершения отдельных этапов испытаний;
• имеющиеся ограничения в условиях проведения испытаний;
• требования к техническому обслуживанию системы;
• меры, обеспечивающие безопасность и безаварийность проведения испытаний;
• порядок взаимодействия организаций, участвующих в испытаниях;
• порядок привлечения экспертов для исследования возможных повреждений в процессе проведения испытаний;
• требования к персоналу, проводящему испытания, и порядок его допуска к испытаниям.
7. Схема организационной структуры содержит:
• состав подразделений (должностных лиц) организации, обеспечивающих функционирование АС либо использующих при принятии решения информацию, полученную от АС;
• основные функции и связи между подразделениями и отдельными должностными лицами, указанными на схеме, и их подчиненность.
8. Описание организационной структуры содержит разделы изменения в организационной структуре управления объектом организация подразделений; реорганизация существующие подразделений управления. В разделе Изменения в организационной структуре управления объектом указывают проектные решения по изменению организационной структуры управления объектом и их обоснование; описание изменений во взаимосвязях между подразделениями. В разделе Организация подразделений приводят: описание организационной структуры и функций подразделений, создаваемых с целью обеспечения функционирования АС; описание регламента работ; перечень категорий работников и число штатных единиц. В разделе Реорганизация существующих подразделений управления указывают описание изменений, обусловленных созданием АС, которые необходимо осуществить в каждом из действующих подразделений управления объектом в организационной структуре, функциях подразделений, регламенте работы, составе персонала подразделений.
9. Методика автоматизированного проектирования содержит разделы: общие положения; постановка задачи; методика проектирования; исходные данные; проектные процедуры; оценка результатов. В разделе Общие положения указывают класс объектов, на которые распространена методика, состав специалистов-пользователей, требования и ограничения на условия применения методики. В разделе Постановка задачи указывают основные пути и направления решения задачи, требования и ограничения на решение, критерии оценки результатов. В разделе Методика проектирования описывают выбранные математические методы, используемые при проектировании, указывают состав и назначение проектных процедур, порядок взаимодействия проектных процедур в процессе выполнения. В разделе Исходные данные определяют состав, порядок выбора, представления и формирования массивов используемой информации, перечень обозначений элементов, описывающих предметную область, с указанием их наименований, единиц измерений, диапазона изменения значений, критерии оценки исходных данных, выбирают методы и модели решения. В разделе Проектные процедуры указывают по каждой проектной процедуре состав нормативно-справочных входных данных, правила доступа к ним, порядок выполнения процедуры, состав и форму выходных сообщений. В разделе Оценка результатов приводят анализ полученного проектного решения на соответствие заданным критериям.
10. Перечень входных сигналов и данных содержит разделы: перечень входных сигналов; перечень входных данных.
В разделе Перечень входных сигналов указывают:
• для аналогового сигнала - наименование измеряемой величины, единицы измерения, диапазон изменения, требования точности и периодичности измерения, тип сигнала;
• для дискретного сигнала - наименование, разрядность и периодичность, тип сигнала;
• для сигнала да-нет - источник формирования и смысловое значение сигнала.
В разделе Перечень входных данных указывают:
• наименование, кодовое обозначение и значность реквизитов входных данных;
• наименования и кодовые обозначения документов или сообщений, содержащих эти данные.
11. Перечень выходных сигналов (документов) содержит разделы: перечень выходных сигналов; перечень выходных документов. Раздел Перечень выходных сигналов содержит перечень выходных сигналов с указанием их наименований, назначения, единиц измерения и диапазонов изменения, способа представления, пользователей информации. Раздел Перечень выходных документов содержит перечень выходных документов с указанием их наименований, кодовых обозначений, перечня и значности реквизитов, пользователей информации.
12. Описание информационного обеспечения системы содержит разделы: состав информационного обеспечения; организация информационного обеспечения; организация сбора и передачи информации; построение системы классификации и кодирования; организация внутримашинной информационной базы; организация внемашинной информационной базы.
В разделе Состав информационного обеспечения указывают наименование и назначение всех баз данных и наборов данных.
В разделе Организация информационного обеспечения приводят:
• принципы организации информационного обеспечения системы;
• обоснование выбора носителей данных и принципы распределения информации по типам носителей;
• описание принятых видов и методов контроля в маршрутах обработки данных при создании и функционировании внемашинной и внутримашинной информационных баз с указанием требований, на соответствие которым проводят контроль;
• описание решений, обеспечивающих информационную совместимость АС с другими системами управления по источникам, потребителям информации, по сопряжению применяемых классификаторов (при необходимости), по использованию в АС унифицированных систем документации.
В разделе Организация сбора и передачи информации приводят:
• перечень источников и носителей информации с указанием оценки интенсивности и объема потоков информации;
• описание общих требований к организации сбора, передачи, контроля и корректировки информации.
В разделе Построение системы классификации и кодирования приводят:
• описание принятых для применения в АС классификаций объектов во вновь разработанных классификаторах и в тех действующих классификаторах, из которых используется часть кода;
• методы кодирования объектов классификации во вновь разработанных классификаторах.
В разделе Организация внутримашинной информационной базы приводят:
• описание принципов построения внутримашинной информационной базы, характеристики ее состава и объема;
• описание структуры внутримашинной информационной базы на уровне баз данных с описанием характера взаимосвязей баз данных и указанием функций АС, при реализации которых используют каждую базу данных, характеристики данных, содержащихся в каждой базе данных.
В разделе Организация внемашинной информационной базы приводят характеристики состава и объема внемашинной информационной базы, принципы ее построения, в том числе основные положения по организации и обслуживанию фонда нормативно-справочной информации во взаимосвязи с автоматизированными функциями.
13. Описание организации информационной базы содержит описание логической и физической структуры базы данных и состоит из двух частей: описание внутримашинной информационной базы; описание внемашинной информационной базы. Части документа содержат следующие разделы: логическая структура; физическая структура (для внутримашинной информационной базы); организация ведения информационной базы. В разделе Логическая структура приводят описание состава данных, их форматов и взаимосвязей между данными. В разделе Физическая структура приводят описание избранного варианта расположения данных на конкретных машинных носителях. При описании структуры внутримашинной информационной базы должны быть приведены перечни баз данных и массивов и логические связи между ними. Для массива информации указывают логическую структуру внутри массива или дают ссылку на документ Описание массива информации. При описании структуры внемашинной информационной базы приводят перечень документов и других информационных сообщений, использование которых предусмотрено в системе, с указанием автоматизируемых функций, при реализации которых формируют или используют данный документ. В разделе Организация ведения информационной базы при описании внутримашинной базы приводят последовательность процедур при создании и обслуживании базы с указанием, при необходимости, регламента выполнения процедур и средств защиты базы от разрушения и несанкционированного доступа, а также с указанием связей между массивами баз данных и массивами входной информации. При описании внемашинной информационной базы должна быть приведена последовательность процедур по маршруту движения групп документов до передачи их на ВЦ, а также описан маршрут движения выходных документов.
14. Описание систем классификации и кодирования содержит перечень применяемых в АС зарегистрированных классификаторов всех категорий по каждому классифицируемому объекту, описание метода кодирования, структуры и длины кода, указания о системе классификации и другие сведения по усмотрению разработчика.
15. Описание массива информации содержит:
• наименование массива;
• обозначение массива;
• наименование носителей информации;
• перечень реквизитов в порядке их следования в записях массива с указанием по каждому реквизиту: обозначения алфавита, длины в знаках и диапазона изменения (при необходимости), логических и семантических связей с другими реквизитами данной записи и другими записями массива;
• оценку объема массива;
• другие характеристики массива (при необходимости).
16. Отчет по ГОСТ 7.32 на стадии Формирование требований к АС содержит разделы:
• характеристика объекта и результатов его функционирования;
• описание существующей информационной системы;
• описание недостатков существующей информационной системы;
• обоснование необходимости совершенствования информационной системы объекта;
• цели, критерии и ограничения создания АС;
• функции и задачи создаваемой АС;
• выводы и предложения.
В разделе Характеристика объекта и результатов его функционирования описывают тенденции развития, требования к объему, номенклатуре и качеству результатов функционирования, а также характер взаимодействия объекта с внешней средой. Раздел Описание существующей информационной системы содержит описание функциональной и информационной структуры системы, качественных и количественных характеристик, раскрывающих взаимодействие ее компонентов в процессе функционирования. В разделе Описание недостатков существующей информационной системы приводят результаты диагностического анализа, при котором оценивают качество функционирования и организационно-технологический уровень системы, выявляют недостатки в организации и технологии функционирования информационных процессов и определяют степень их влияния на качество функционирования системы. В разделе Обоснование необходимости совершенствования информационной системы объекта при анализе соответствия показателей функционирования объекта предъявляемым требованиям оценивают степень соответствия прогнозируемых показателей требуемым, а также выявляют необходимость совершенствования информационной системы путем создания АС. Раздел Цели, критерии и ограничения создания АС содержит: формулировку производственно-хозяйственных, научно- технических и экономических целей и критериев создания АС; характеристику ограничений по созданию АС.
Раздел Функции и задачи создаваемой АС содержит:
• обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения;
• требования к характеристикам реализации функций и задач в соответствии с действующими нормативно-техническими документами, определяющими общие технические требования к АС конкретного вида;
• дополнительные требования к АС в целом и ее частям, учитывающие специфику создаваемой АС.
Раздел Ожидаемые технико-экономические результаты создания АС содержит:
• перечень основных источников экономической эффективности получаемых в результате создания АС (в том числе – экономия производственных ресурсов, улучшение качества продукции, повышение производительности труда и т. д.) и оценку ожидаемых изменений основных технико-экономических и социальных показателей производственно-хозяйственной деятельности объекта (например, показателей по номенклатуре и объемам производства, себестоимости продукции, рентабельности, отчислениям в фонд экономического стимулирования, уровню социального развития);
• оценку ожидаемых затрат на создание и эксплуатацию АС с распределением их по очередям создания АС и по годам;
• ожидаемые обобщающие показатели экономической эффективности АС.
Раздел Выводы и предложения рекомендуется разделять на подразделы: выводы о производственно-хозяйственной необходимости и технико-экономической целесообразности создания АС; предложения по совершенствованию организации и технологии процесса деятельности; рекомендации по созданию АС. одраздел Выводы о производственно-хозяйственной необходимости и технико-экономической целесообразности создания АС содержит: сопоставление ожидаемых результатов создания АС с заданными целями и критериями создания АС (по целевым показателям и нормативным требованиям); принципиальное решение вопроса о создании АС (положительное или отрицательное). Подраздел Предложения по совершенствованию организации и технологии процесса деятельности содержит предложения по совершенствованию: производственно-хозяйственной деятельности; организационной и функциональной структур системы, методов деятельности, видов обеспечения АС. Подраздел Рекомендации по созданию АС содержит рекомендации:
• по виду создаваемой АС, ее совместимости с другими АС и неавтоматизируемой частью соответствующей системы;
• по организационной и функциональной структуре создаваемой АС;
• по составу и характеристикам подсистем и видов обеспечения АС;
• по организации использования имеющихся и приобретению дополнительных средств вычислительной техники;
• по рациональной организации разработки и внедрения АС;
• по определению основных и дополнительных, внешних и внутренних источников и видов объемов финансирования и материального обеспечения разработок АС;
• по обеспечению производственных условий создания АС;
• другие рекомендации по созданию АС.
17. Отчет по ГОСТ 7.32 на стадии Разработка концепции АС содержит:
• описание результатов изучения объекта автоматизации;
• описание и оценку преимуществ и недостатков разработанных альтернативных вариантов концепции создания АС;
• сопоставительный анализ требований пользователя к АС и вариантов концепции АС на предмет удовлетворения требованиям пользователя;
• обоснование выбора оптимального варианта концепции и описание предлагаемой АС;
• ожидаемые результаты и эффективность реализации выбранного варианта концепции АС;
• ориентировочный план реализации выбранного варианта концепции АС;
• необходимые затраты ресурсов на разработку, ввод в действие и обеспечение функционирования;
• требования, гарантирующие качество АС;
• условия приемки системы.
ПЗ.3. ГОСТ 234.003-90. Автоматизированные системы. Термины и определения
Настоящий стандарт устанавливает термины и определения основных понятий в области автоматизированных систем (АС) и распространяется на АС, используемые в различных сферах деятельности (управление, исследования, проектирование и т.п., включая их сочетание), содержанием которых является переработка информации.
Автоматизированная система. Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
Интегрированная АС. Совокупность двух или более взаимоувязанных АС, в которой функционирование одной из них зависит от результатов функционирования другой (других) так, что эту совокупность можно рассматривать как единую АС.
Функция АС. Совокупность действий АС, направленная на достижение определенной цели.
Алгоритм функционирования АС. Алгоритм, задающий условия и последовательность действий компонентов автоматизированной системы при выполнении ею своих функций.
Пользователь АС. Лицо, участвующее в функционировании АС или использующее результаты ее функционирования.
Организационное обеспечение АС. Совокупность документов, устанавливающих организационную структуру, права и обязанности пользователей и эксплуатационного персонала АС в условиях функционирования, проверки и обеспечения работоспособности АС.
Методическое обеспечение АС. Совокупность документов, описывающих технологию функционирования АС, методы выбора и применения пользователями технологических приемов для получения конкретных результатов при функционировании АС.
Техническое обеспечение АС. Совокупность всех технических средств, используемых при функционировании АС.
Математическое обеспечение АС. Совокупность математических методов, моделей и алгоритмов, примененных в АС.
Программное обеспечение АС. Совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС.
Информационное обеспечение АС. Совокупность форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации, применяемой в АС при ее функционировании.
Лингвистическое обеспечение АС. Совокупность средств и правил для формализации естественного языка, используемых при общении и пользователей и эксплуатационного персонала АС с комплексом средств автоматизации при функционировании АС.
Правовое обеспечение АС. Совокупность правовых норм, регламентирующих правовые отношения при функционировании АС и юридический статус результатов ее функционирования.
Эргономическое обеспечение АС. Совокупность реализованных решений в АС по согласованию психологических, психофизиологических, антропометрических, физиологических характеристик и возможностей пользователей АС с техническими характеристиками комплекса средств автоматизации АС и параметрами рабочей среды на рабочих местах персонала АС.
Компонент АС – часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое.
Информационная база АС. Совокупность упорядоченной информации, используемой при функционировании АС.
Внемашинная информационная база АС. Часть информационной базы АС, представляющая собой совокупность документов, предназначенных для непосредственного восприятия человеком без применения средств вычислительной техники.
Машинная информационная база АС. Часть информационной базы АС, представляющая собой совокупность используемой в АС информации на носителях данных.
Автоматизированное рабочее место (АРМ). Программно-технический комплекс АС, предназначенный для автоматизации деятельности определенного вида.
Эффективность АС. Свойство АС, характеризуемое степенью достижения целей, поставленных при ее создании.
Совместимость АС. Комплексное свойство двух или более АС, характеризуемое их способностью взаимодействовать при функционировании (включающее техническую, программную, информационную, организационную и лингвистическую совместимость).
Адаптивность АС. Способность АС изменяться для сохранения своих эксплуатационных показателей в заданных пределах при изменениях внешней среды.
Надежность АС. Комплексное свойство АС сохранять во времени в установленных пределах значения всех параметров, характеризующих способность АС выполнять свои функции в заданных режимах и условиях эксплуатации.
Живучесть АС. Свойство АС, характеризуемое способностью выполнять установленный объем функций в условиях воздействий внешней среды и отказов компонентов системы в заданных пределах.
Жизненный цикл АС. Совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС.
Сопровождение АС. Деятельность по оказанию услуг, необходимых для обеспечения устойчивого функционирования или развития АС.
Диалоговый режим выполнения функции АС. Режим выполнения функции АС, при котором человек управляет решением задачи, изменяя ее условия и/или порядок функционирования АС на основе оценки информации, представляемой ему техническими средствами АС.
Техническое задание на АС. Документ, оформленный в установленном порядке и определяющий цели создания АС, требования к АС и основные исходные данные, необходимые для ее разработки, а также план-график создания АС.
Технический проект АС. Комплект проектных документов на АС, разрабатываемый на стадии Технический проект, утвержденный в установленном порядке, содержащий основные проектные решения по
системе в целом, ее функциям и всем видам обеспечения АС и достаточный для разработки рабочей документации на АС.
Рабочая документация на АС. Комплект проектных документов на АС, разрабатываемый на стадии Рабочая документация, содержащий взаимоувязанные решения по системе в целом, ее функциям, всем видам обеспечения АС, достаточные для комплектации, монтажа, наладки и функционирования АС, ее проверки и обеспечения работоспособности.
Эксплуатационная документация на АС. Часть рабочей документации на АС, предназначенная для использования при эксплуатации системы, определяющая правила действия персонала и пользователей системы при ее функционировании, проверке и обеспечении ее работоспособности.
Технорабочий проект АС. Комплект проектных документов АС, утвержденный в установленном порядке и содержащий решения в объеме технического проекта и рабочей документации на АС.
Входная информация АС. Информация, поступающая в АС в виде документов, сообщений, данных, сигналов, необходимая для выполнения функций АС.
Выходная информация АС. Информация, получаемая в результате выполнения функций АС и выдаваемая на объект ее деятельности, пользователю или в другие системы.
Нормативно-справочная информация АС. Информация, заимствованная из нормативных документов и справочников и используемая при функционировании АС.


    Бухгалтерия: Автоматизация - Система 1С

• Бухгалтерия
  
• Бухгалтерская отчетность
  
• Автоматизация бухгалтерии
  
• Расчет налогов
  
• Бухгалтерские расчеты
  
  
• Бухгалтерский учет
  
  
• Бухгалтерия в 1С
  
• 1С - конфигурации
  
• 1С версия 7.7
  
• 1С версия 8.0
  
• 1С 8.0 программирование