Финансы АО

(3.4%)4469/310.034*str(??)250Удержано в фонд медицинского страхования (3.4%)4469/320.002*str(??)260Удержано в фонд занятости (1.5%)4469/40.015*str(??)270Удержан транспортный налог (1%)4468/70.01*str(??)280Удержан сбор на образование (1%)8068/80.01*str(??)

Создание документации на проект.

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

Создание инструкций по работе в Системе.

Созданием инструкций заканчивается этап создания проекта. Инструкции в проекте делятся на 3 типа. 1. Инструкции по организации работ в различных режимах работы Системы. Пример: Приложение 6. “Инструкция пользователя при работе в режиме Off-Line” 2. Инструкция для администратора Системы. Администратор Системы является человеком на предприятии, осуществляющем надзор за состоянием Системы; администратор осуществляет обновление Системы, передачу данных при работе в режиме Off-Line. Администратору Системы передается проектная документация. При эксплуатации Системы он имеет права на заведение дополнительных образцов документов, исправление прав доступа в соответствии с изменениями в работе предприятия. Администратор осуществляет связь с представительством “Паруса”, по поводу изменений в Системе и др. Таким образом, администратор является своего рода представителем “Паруса”, на которого ложится вся тяжесть по сопровождению Системы. Инструкция для администратора входит в основную часть проектной документации и представляет собой тезисы по общему сопровождению Системы и особенности, касающиеся реализации конкретного проекта. 3. Создание инструкций для рабочих мест. Инструкции для рабочих мест представляют собой конкретные действия сотрудника при выполнении тех или иных этапов бизнес-процессов. Существование инструкций позволяет пользователю не копаться в документации по Системе, а всегда иметь под рукой краткое описание своих действий. Инструкции для рабочих мест оформляются как Приложение к проектной документации.

Разработка аналитических отчетов с использованием генератора отчетов.

При проведении комплексного обследования выясняется потребность Заказчика в специальных отчетах. После проведения анализа сложности и возможности реализации отчета в Системе Заказчику выставляется счет на разработку отчета (Стоимость также может изначально закладываться в стоимость Договора на проектные работы). Разработка отчетов начинается после создания макета, когда определятся таблицы и поля БД, необходимые для отчета.

Защита макета Системы и проектной документации.

Составление плана защиты.

По завершении работ над макетом и документацией к проекту Проектировщик готовится к защите Проекта. Защита проводится в 3 этапа. 1. Внутренняя защита проекта 2. Защита на рабочих местах 3. Комплексная защита Для проведения защиты Проектировщик готовит план показа макета.

Пример плана защиты:

1. Общее знакомство с Системой. 2. Словари Системы, Прайс-лист, Склады (структура, принципы заведения позиции) 3. Образцы документов. 4. Работа с документами по схемам бизнес-процессов. 5. Показ документации в части схем бизнес-процессов. 6. Формирование отчетов (Оперативных, бухгалтерских). 7. Представление инструкций для рабочих мест. 8. Представление Плана перехода на Систему АФХД “Парус”. 9. Ответы на вопросы.

Внутренняя (в “Парусе”) предзащита проекта и документации.

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

Согласование и подписание приказа о начале работ.

После принятия Проекта в “Парусе” (и согласно срокам Договора) Менеджер Проекта извещает Заказчика о готовности проведения защиты Проекта на рабочих местах. Для обеспечения четкой организации проведения защиты Проекта Менеджер Проекта предлагает Заказчику образец приказа о проведения защиты на рабочих местах. В приказе оговариваются сроки и время проведения защиты, присутствие сотрудников подразделений, обеспечение техникой.

Защита макета на рабочих местах.

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

Комплексная защита макета.

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

Оформление перечня требований и доработок как в ПО, так и в макете.

После ознакомления Заказчика с документацией и макетом Системы Заказчик и Менеджер Проекта оформляют протокол замечаний по Проекту. В протоколе указываются конкретные недостатки Проекта (неправильный шаблон документа, неверный порядок этапов, отсутствие функций в программе). Менеджер Проекта разделяет все замечания на 2 раздела: претензии к ПП и претензии к Проекту. Замечания к ПП рассматриваются с точки зрения целесообразности доработки ПП. В случае справедливости замечаний проводятся консультации с ЦИТ по поводу доработок в ПП. Возможны 3 варианта: 1. Замечания о несоответствии ПП законодательству проверяются и, при подтверждении,