Дипломная работа: Моделирование бизнес-процессов на примере компании-разработчика программного обеспечения

Курсовая работа

Моделирование бизнес-процессов на примере компании-разработчика программного обеспечения

стратегический цель совершенствование компания

Введение

Введение

Данная аттестационная работа направлена на описание и оптимизацию бизнес-процессов компании-разработчика программного обеспечения (далее – ПО).

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

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

Целью данной работы является выработка стандартов работы компании и оптимизация существующих бизнес-процессов. В работе необходимо выполнить следующие задачи:

-  стратегический анализ деятельности компании;

-  описание текущего положения и штатной структуры компании;

-  описание существующих бизнес-процессов;

-  анализ и оптимизация бизнес-процессов, выработка рекомендаций по их изменению, регламентирование деятельности;

-  оптимизация штатной структуры компании;

-  анализ проблем и выработка решений по управленческим и кадровым проблемам компании;

-  создание образцов типовых документов;

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

1.Стратегический анализ деятельности компании

Основными направлениями деятельности компании являются:

-  разработка программного обеспечения (ПО);

-  внедрение и сопровождение программного обеспечения;

-  поставка аппаратного обеспечения;

-  техническая поддержка.

При этом разработка ПО ведется в двух направлениях – ПО сферы бухгалтерского учета разрабатывается на одной платформе, а ПО остальных направлений – на другой (т.н. ИИС).

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

Организационно-штатная структура компании еще больше усугубляет вышеуказанные проблемы.

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

Описание организации приведено в Таблице 1.

Таблица 1.Описание организации как объекта управления

1.2 Организационно-штатная структура

Существующая штатная структура организации приведена на Рисунке 1.

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

Управление системной интеграции фактически является независимым подразделением, в обязанности которого входят аппаратное обеспечение и техническая поддержка.

Кадровая служба не существует в виде отдельного подразделения.

Рисунок 1. Существующая штатная структура.

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

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

1.3 Основные проблемы управления

В рассматриваемой организации существует ряд нижеперечисленных проблем управления.

Отсутствие чётко сформулированной стратегии. Направления развития выбираются скорее исходя из текущих запросов рынка. Отсутствует видение ситуации на несколько шагов вперёд.

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

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

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

Отсутствие планирования. Часто приводит к авральному выполнению проектов и нехватке сотрудников.

Слаборазвитая система отчётов и документирования проектов. Это влечёт за собой недостаточную информированность, а иногда даже частичную незаменимость сотрудника, участвовавшего в конкретном проекте

Отсутствие чётко сформулированных должностных обязанностей сотрудников. Нет формализованного описания действий и требований по выполнению конкретных работ. Информация часто передается из уст в уста, нет установленной программы обучения новых сотрудников.

1.4 Постановка стратегических целей

В данный момент миссия и стратегия компании не сформулированы, поэтому попытаюсь их формулировать на основе собственного понимания и когда-то услышанных мыслей руководителя.

Миссия

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

Стратегический профиль

Текущую стратегию я бы сформулировал следующим образом:

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

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

Видение (стратегическое намерение)

1.  Какой мы хотим видеть свою организацию в будущем?

Известный бренд на рынке информационных систем и системной интеграции. Один из крупнейших представителей в данном сегменте. Продукты и услуги компании являются образцом для подражания и устанавливают моду.

2.  Что из себя представляет наш бизнес сейчас и каким он будет в будущем?

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

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

3.  Кто является потребителями нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем?

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

4.  Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей?

Следовать последним тенденциям в области разработки. Провести реинжиниринг в соответствии с требованиями ISO9001 и пройти сертификацию. Повысить качество продукта путем улучшения качества проектирования и ввода многоуровневой системы тестирования. Уделять больше внимания вопросам информационной безопасности. Создать консолидированную систему отчётности и базу знаний. Улучшить качество управления персоналом для повышения эффективности.

Стратегические цели

1.  Сроки стратегического планирования.

Учитывая текущее состояние дел в компании, количество заказов и тенденции развития технологий будет выбран двухлетний период

2.  Генеральная цель.

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

Декомпозиция генеральной цели. Определение ключевых целей по функциональным подсистемам.

-  Завершить реорганизацию структуры (создание новых структурных подразделений и распределение функций между ними)

-  Выделение в отдельную структуру аналитиков и проектировщиков.

-  Создание единого подразделения разработки программных продуктов с чётким разделением на разработчиков единой интегрированной платформы и структурные единицы по принадлежности к технологическим платформам.

Повысить профессиональный уровень сотрудников

-  Создать систему обучения вновь принятых сотрудников

-  Внедрить систему аттестации сотрудников

-  Организовать процесс повышения профессиональной подготовки кадров

-  Проведение тематических семинаров

Формализовать процессы.

-  Разработать должностные инструкции, ввести четкое разграничение полномочий

-  Перейти к грамотной, качественной и формализованной постановке задач

-  Организовать процесс документирования производимых работ

-  Стандартизировать процессы планирования и отчётности

1.5 Анализ и выбор стратегии

Результаты SWOT-анализа приведены в таблице 2 и таблице 3.

Таблица 2.Анализ факторов, воздействующих на достижение стратегических целей

Таблица 3.Итоговая стратегическая матрица

Граф типовых стратегий организации приведен на рисунке 2.

Выбор и обоснование стратегии

В таблице 4 приведен выбор и оценка факторов, задействованных в трёх базовых стратегиях.

Таблица 4.Выбор и оценка факторов, задействованных в трёх базовых стратегиях

По сумме оценок:

По сумме оценок наилучшей стратегией является стратегия дифференциации.

По реальности задействованных факторов:

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

Выбранная стратегия

Возможные действия в рамках реализации стратегии:

-  Совершенствование и расширение линейки продуктов

-  Повышение профессионального уровня сотрудников

-  Повышение значимости планирования.

-  Агрессивная маркетинговая политика расширение партнёрских отношений.

Возможные последствия реализации выбранной стратегии

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

К недостаткам можно отнести следующее:

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

Надо очень серьёзно прорабатывать данные вопросы во избежание негативного влияния.

Реализация системы планов. Эффективность изменений

Определение необходимых изменений приводится в таблице 5.

Таблица 5.Определение необходимых изменений

Разработка мероприятий, программ и планов

Планирование

1.  Создание плана реорганизации.

2.  Планирование рабочего времени сотрудников.

3.  Создание маркетингового плана

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

Организация

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

1.  Реорганизация имеющихся департаментов и отделов, создание новых функциональных единиц, модернизация нового штатного расписания.

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

3.  Написание детальных должностных инструкций

4.  Детальное распределение полномочий и распределение проектов. Назначение ответственного за результат.

Мотивация

В таблице 6 приводятся показатели качества трудовой жизни.

Таблица 6.Показатели качества трудовой жизни

Исходя из перечисленных проблем в модели 7S и описания качества трудовой жизни – отсутствует формализованная система мотивации. Введен учёт по времени прихода на работу, но отсутствует фиксация отработанного времени (сотрудники часто работают по 12 часов - но это не учитывается). Отсутствует система определения квалификации сотрудников. Определение вклада в общее дело носит субъективный характер и иногда зависит от личных симпатий. Соответственно, необходимо разработать данную систему и утвердить ее на коллективном собрании сотрудников и учредителей.

Контроль

1.  Внедрить в компании стандарты ISO9001, при необходимости разработать собственные стандарты качества. Ввести многоуровневые системы тестирования и контроля качества продуктов и услуг.

2.  Разработать систему аттестации сотрудников. Проводить ей с установленной периодичностью. По результатам принимать решение об обучении, премировании, повышении в должности, расширении полномочий.

3.  Доработка внутренней ИС компании. Ведение отчетности, контроль выполнения и занятости, сравнительный анализ.

Оценка эффективности предлагаемых изменений

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

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

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

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

2.Анализ и оптимизация бизнес-процессов

2.1 Описание бизнес-процессов «как есть»

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

Разработка

Процесс разработки новых прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 3):

-  постановка задачи;

-  разработка;

-  тестирование;

-  документирование.

Рисунок 3. Виды деятельности при разработке новых систем и роли

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

Диаграмма деятельности для стадии постановки задачи приведена на Рисунке 4.

Рисунок 4. Диаграмма деятельности для стадии постановки задачи

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

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

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

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

Внедрение и сопровождение

Процесс внедрения, а также последующего сопровождения прикладных систем, как правило, состоит из следующих видов деятельности (Рисунок 5):

-  установка ПО;

-  обучение пользователей;

-  сбор замечаний;

-  устранение замечаний;

-  модернизация ПО.

Рисунок 5. Виды деятельности при внедрении и сопровождении

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

В таблице 7 приведены сводные данные по ролям и функциям.

Таблица 7.Сводная таблица ролей и функций

2.2 Проблемы и задачи

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

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

Основными задачами в части реорганизации бизнес-процессов является:

-  определение наиболее удобного типа процесса разработки для новых проектов;

-  определение типа процесса для сопровождения существующих проектов;

-  выработка стандарта планирования новых проектов и сопровождения существующих проектов;

-  определение перечня документов, поддерживающих жизненный цикл проекта, а также лиц, ответственных за формирование данных документов.

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

2.3 Анализ типовых вариантов процессов разработки

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

На рисунке 6 приведен водопадный процесс разработки с указанием результатов на каждом этапе.

Рисунок 6. Водопадный процесс разработки

Спиральный процесс

В случае спирального процесса последовательность «анализ – проектирование – реализация – тестирование» выполняется несколько раз. Основные причины использования спирального процесса обычно следующие:

-  необходимость предупреждения рисков;

-  необходимость предоставить заказчику частичную версию проекта до его завершения.

Основной трудностью использования спирального процесса является поддержка актуальности документации.

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

Рисунок 7. Спиральный процесс разработки

Инкрементальный процесс

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

Унифицированный процесс

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

На рисунке 8 приведен унифицированный процесс разработки.

Рисунок 8. Унифицированный процесс разработки

Исходя из всего вышесказанного, наиболее удобным и оправданным является использование:

-  для разработки новых проектов – унифицированного процесса разработки;

-  для сопровождения – использование инкрементального процесса.

2.4 Оптимизация процессов разработки и сопровождения

При переходе к проектному управлению необходима реорганизация бизнес-процессов в соответствии с жизненным циклом реализации проектов. Жизненный цикл проекта – это комбинация процессов и подпроцессов, необходимых для создания (реализации) объекта или решения. Так, жизненный цикл проекта в стандарте PMI (Project Management Institute, США) состоит из следующих фаз:

-  начальная фаза (инициирование проекта);

-  разработка;

-  реализация;

-  завершение.

Каждая фаза характеризуется получением одного или нескольких результатов, достигаемых в заданное время.

Фазы могут обладать следующими характеристиками:

-  границы;

-  вход, выход;

-  длительность;

-  операции;

-  участники;

-  бюджеты.

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

-  процесс инициирования – принятие решения о начале выполнения проекта;

-  процесс планирования – определение целей и критериев успеха проекта и разработка рабочих схем их достижения;

-  процесс исполнения – координация людей и других ресурсов для выполнения плана;

-  процесс анализа – определение соответствия плана и исполнения проекта поставленным целям и критериям и принятие решения о корректирующих воздействиях;

-  процесс управления – определение корректирующих воздействий, их согласование, утверждение и применение;

-  процесс завершения – формализация выполнения проекта и приведение его к упорядоченному финалу.

Процессы управления проектами приведены на рисунке 9.

Рисунок 9. Процессы управления проектами

Каждый этап управления обладает следующими характеристиками:

-  границы;

-  документы на входе, документы на выходе;

-  временной регламент;

-  операции;

-  участники.

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

-  рассмотрение управления потоком проектов с позиции общих корпоративных целей компании;

-  ведение систематизированного реестра проектов, позиционирование проектов по классификаторам реестра, задание типологии основных групп проектов;

-  дифференцированное применение моделей управления для различных групп проектов, формирование механизмов управления проектами или группами проектов в зависимости от прав, переданных центрам проектных компетенций;

-  создание иерархической архитектуры системы управления проектами;

-  использование возможностей мультипроектного управления ресурсами, составление балансов по ограниченным ресурсам;

-  формирование и использование корпоративной мультипроектной базы данных;

-  формализация, накопление и анализ опыта реализации проектов и непрерывное совершенствование корпоративных стандартов их выполнения (технологии, процедуры, организационные структуры, бизнес-процессы), построение менеджмента, основанного на знаниях;

-  бюджетирование проектов, включение бюджета проектов в основной бюджет компании.

В рамках данной работы рассматриваются две группы процессов:

-  проекты по разработке новых прикладных систем;

-  проекты по сопровождению существующих систем.

Первая группа проектов полностью соответствует общепринятому пониманию термина «проект», т.к. в результате производится уникальный продукт – новая прикладная система, которая в дальнейшем может пойти в массовое распространение, внедрение и сопровождение.

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

3.Результаты и рекомендации

3.1 Описание бизнес-процессов «как должно быть

Жизненный цикл нового проекта представлен на диаграмме деятельности (Рисунок 10).

Рисунок 10. Жизненный цикл нового проекта

Создание Устава проекта

Устав проекта – официальный письменный документ, который формально признает и подтверждает факт существования проекта. Создание Устава проекта позволяет достичь следующих целей:

-  официальное подтверждение начала реализации проекта;

-  выделение проектных ресурсов;

-  обеспечение единства целей;

-  назначение руководителя проекта;

-  изложение общего содержания и целей проекта;

-  определение масштаба проекта и количества итераций.

Документы на входе:

-  имеющаяся исходная документация по проекту (контракт, постановка задачи, общее описание и пр.).

Документы на выходе:

-  Устав проекта.

Временной регламент:

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

Операции:

-  определение общего содержания проекта;

-  определение целей и задач проекта;

-  определение требований;

-  коммерческое обоснование;

-  оценка затрат и ресурсов;

-  определение функций и обязанностей.

Участники:

-  руководитель проекта;

-  заинтересованные лица.

Определение плана итераций

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

Документы на входе:

-  Устав проекта.

Документы на выходе:

-  План итераций.

Временной регламент:

-  1-5 дней.

Операции:

-  определение сроков завершения каждой итерации;

-  определение результатов каждой итерации.

Участники:

-  руководитель проекта;

-  заинтересованные лица.

Планирование итерации

Итерации планируются последовательно, в каждый момент времени известен план текущей итерации. При высокой степени определенности проекта возможно планирование текущей и следующей итераций. Для каждой итерации определяются проводимые стадии и сроки их завершения. Следует учесть, что желательно на разработку выделить около 1/6 общей длительности итерации, наиболее длительная стадия – проектирование.

Документы на входе:

-  Устав проекта;

-  План итераций.

Документы на выходе:

-  План следующей итерации.

Временной регламент:

-  1-5 дней.

Операции:

-  определение выполняемых стадий (анализ, проектирование, реализация, тестирование);

-  определение сроков завершения каждой стадии;

-  определение результатов каждой стадии;

-  определение ресурсов и ответственных.

Участники:

-  руководитель проекта;

-  заинтересованные лица.

Планирование каждой стадии

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

Документы на входе:

-  План текущей итерации;

-  Результаты предыдущей итерации;

-  Результаты предыдущей стадии.

Документы на выходе:

-  План текущей стадии.

Временной регламент:

-  1-2 дня.

Операции:

-  декомпозиция стадии на задачи;

-  определение сроков завершения каждой задачи;

-  определение ресурсов и ответственных.

Участники:

-  руководитель проекта;

-  заинтересованные лица.

Выполнение каждой стадии

Выполнение каждой стадии происходит параллельно с планированием следующей стадии (при ее наличии).

Документы на входе:

-  План текущей стадии.

Документы на выходе:

-  для стадии анализа:

o  постановка задачи (ТЗ и пр.) (образец документа приведен в Приложении 1);

o  тестовый пример (образец документа приведен в Приложении 1);

-  для стадии проектирования:

o  технический проект (образец документа приведен в Приложении 1);

-  для стадии реализации:

o  описание реализации (образец документа приведен в Приложении 1);

o  краткое руководство (образец документа приведен в Приложении 1);

-  для стадии тестирования:

o  отчет о тестировании (образец документа приведен в Приложении 1);

o  ведомость замечаний (образец документа приведен в Приложении 1);

o  отчет об устранении замечаний (образец документа приведен в Приложении 1).

Временной регламент:

-  срок выполнения каждой задачи должен соответствовать сроку, указанному в плане текущей стадии;

-  срок выполнения каждой стадии должен соответствовать сроку, указанному в плане текущей итерации.

Операции:

-  выполнение задачи;

-  подготовка и согласование результирующих документов.

Участники:

-  руководитель проекта;

-  исполнители задач.

Контроль исполнения

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

Документы на входе:

-  Устав проекта;

-  План итераций;

-  План текущей итерации;

-  План текущей стадии;

-  Результаты выполнения задач:

o  постановка задачи;

o  тестовый пример;

o  технический проект;

o  описание реализации;

o  краткое руководство;

o  отчет о тестировании;

o  ведомость замечаний;

o  отчет об устранении замечаний.

Документы на выходе:

-  Устав проекта;

-  План итераций;

-  План текущей итерации;

-  План текущей стадии.

Временной регламент:

-  контроль исполнения должен производиться постоянно по завершении стадий и итераций, а также с заданной периодичностью в течение всего хода проекта.

Операции:

-  контроль сроков;

-  контроль качества результатов;

-  перераспределение ресурсов;

-  внесение изменений в планы;

-  внесение изменений в Устав проекта;

-  подготовка и согласование результирующих документов.

Участники:

-  руководитель проекта;

-  исполнители задач.

Завершение проекта

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

Документы на входе:

-  полный объем проектной документации.

Документы на выходе:

-  архив проектных документов;

-  замечания и предложения по проекту.

Временной регламент:

-  5-10 дней; также зависит от сроков окончательных расчетов.

Операции:

-  финальные процедуры контроля проекта;

-  закрытие контрактов, проведение расчетов;

-  формирование замечаний и предложений по проекту;

-  архивирование проектной документации.

Участники:

-  руководитель проекта;

-  проектная группа и прочие заинтересованные лица.

Проекты по сопровождению

Жизненный цикл проекта по сопровождению представлен на диаграмме деятельности (Рисунок 11) с указанием входной и выходной информации и ролей пользователей.

Рисунок 11. Жизненный цикл проекта по сопровождению

Создание Устава проекта

Документы на входе:

-  имеющаяся исходная документация по проекту (контракт, условия обслуживания, соглашения и пр.).

Документы на выходе:

-  Устав проекта.

Временной регламент:

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

Операции:

-  определение общего содержания проекта;

-  определение целей и задач проекта;

-  определение порядка сопровождения;

-  определение плана выпуска обновлений и их объема;

-  коммерческое обоснование;

-  оценка затрат и ресурсов;

-  определение функций и обязанностей.

Участники:

-  руководитель проекта;

-  заинтересованные лица.

Определение плана выпуска обновлений

Исходя из Устава проекта, определяется план выпуска обновлений и приблизительный объем каждого обновления (например, по количеству заявок).

Документы на входе:

-  Устав проекта.

Документы на выходе:

-  План выпуска обновлений.

Временной регламент:

-  1-2 дня.

Операции:

-  определение сроков выпуска обновлений;

-  определение объема обновлений.

Участники:

-  руководитель проекта;

-  заинтересованные лица.

Планирование итерации

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

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

Документы на входе:

-  План выпуска обновлений;

-  Заявки пользователей на сопровождение.

Документы на выходе:

-  План итерации.

Временной регламент:

-  планирование следующих итераций происходит по мере выполнения текущей итерации; к моменту завершения текущей итерации план должен быть готов.

Операции:

-  рассмотрение заявки;

-  включение заявки в план;

-  декомпозиция плана на задачи;

-  определение сроков завершения каждой задачи;

-  определение ресурсов и ответственных.

Участники:

-  руководитель проекта.

Выполнение итерации

Выполнение итерации происходит параллельно с планированием следующей итерации (при ее наличии).

Документы на входе:

-  План текущей итерации.

Документы на выходе:

-  для стадии анализа:

o  заявка (образец документа приведен в Приложении 1);

o  тестовый пример (образец документа приведен в Приложении 1);

-  для стадии проектирования:

o  технический проект;

-  для стадии реализации:

o  описание реализации (образец документа приведен в Приложении 1);

o  краткое руководство (образец документа приведен в Приложении 1);

-  для стадии тестирования:

o  отчет о тестировании (образец документа приведен в Приложении 1);

o  ведомость замечаний (образец документа приведен в Приложении 1);

o  отчет об устранении замечаний (образец документа приведен в Приложении 1);

-  для стадии внедрения:

o  отчет об установке обновления/программного обеспечения (образец документа приведен в Приложении 1);

o  ведомость обучения (образец документа приведен в Приложении 1).

Временной регламент:

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

Операции:

-  выполнение задачи;

-  подготовка и согласование результирующих документов;

-  переход на следующую стадию.

Участники:

-  руководитель проекта;

-  исполнители задач.

Контроль исполнения

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

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

Общий и детализированный план должен быть доступен всем заинтересованным лицам.

Документы на входе:

-  Устав проекта;

-  План выпуска обновлений;

-  Планы итераций;

-  Результаты выполнения задач:

o  заявка;

o  тестовый пример;

o  технический проект;

o  описание реализации;

o  краткое руководство;

o  отчет о тестировании;

o  ведомость замечаний;

o  отчет об устранении замечаний;

o  отчет об установке обновления/программного обеспечения;

o  ведомость обучения.

Документы на выходе:

-  Устав проекта;

-  План выпуска обновлений;

-  Планы итераций.

Временной регламент:

-  контроль исполнения должен производиться постоянно по завершении стадий и итераций, а также с заданной периодичностью в течение всего хода проекта.

Операции:

-  контроль сроков;

-  контроль качества результатов;

-  перераспределение ресурсов;

-  внесение изменений в планы;

-  внесение изменений в Устав проекта;

-  подготовка и согласование результирующих документов.

Участники:

-  руководитель проекта;

-  исполнители задач.

Завершение проекта

Документы на входе:

-  полный объем проектной документации.

Документы на выходе:

-  архив проектных документов;

-  замечания и предложения по проекту.

Временной регламент:

-  5-10 дней; также зависит от сроков окончательных расчетов.

Операции:

-  финальные процедуры контроля проекта;

-  закрытие контрактов, проведение расчетов;

-  формирование замечаний и предложений по проекту;

-  архивирование проектной документации.

Участники:

-  руководитель проекта;

-  проектная группа и прочие заинтересованные лица.

Управление ходом проекта

Процесс перехода между стадиями

В процессе перехода продукта с одной стадии на другую в рамках текущей итерации, как правило, происходит тесное взаимодействие между исполнителями этих стадий (Рисунок 12).

Рисунок 12. Взаимодействие между исполнителями стадий

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

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

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

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

Для упорядочивания процесса разработки продуктов предлагается следующий порядок:

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

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

Взаимодействие в красной зоне должно происходить только с уведомлением руководителя проекта об обнаруженных вопросах, фиксироваться документально и приводить к пересмотру плана проекта.

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

Документирование процесса перехода между стадиями

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

Рисунок 13. Документирование процесса перехода между стадиями

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

Исправления, вносимые по результатам замечаний, также должны оформляться документально в виде протокола устранения замечаний.

Если исправления вносятся на текущей стадии:

-  увеличивается срок предыдущей стадии в связи с необходимостью исправления замечаний;

-  возможно, увеличивается срок текущей стадии (в связи с изменением объема работ, в связи с необходимостью ожидания исправлений).

Образцы и краткое содержание документов, указанных на рисунке, приведены в Приложении 1.

Процесс перехода между итерациями

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

В результате завершения итерации в хранилище данных по проекту, доступном всем заинтересованным лицам, должны находиться следующие данные:

-  пронумерованная версия продукта (библиотеки, исполняемые файлы, база данных и пр.);

-  описание функциональности, добавленной по сравнению с предыдущей версией;

-  пронумерованные версии всех проектных документов на момент завершения итерации.

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

Процесс перехода продукта из разработки во внедрение и сопровождение

При передаче продукта из разработки во внедрение и дальнейшее сопровождение руководитель проекта (при его отсутствии – руководитель подразделения, ответственного за внедрение) составляет план внутренней приемки продукта, в котором должны быть отражены следующие этапы:

-  ознакомление с проектной документацией;

-  демонстрация программного продукта;

-  обучение сотрудников внедрения работе с продуктом.

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

Оценка деятельности

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

Большое количество документов «Уведомление об изменении требований» свидетельствует о недостаточной проработке соответствующих вопросов во время выполнения стадии, и, соответственно, о низком качестве работы исполнителей.

Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.

Влияние данных документов на конечный результат можно оценить с помощью зоны, в которую попадали документы: зеленая зона – незначительное влияние, оранжевая зона – среднее влияние, красная зона – значительное влияние, черная зона – очень серьезное влияние.

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

3.2 Изменения в организационно-штатной структуре

Изменения в организационно-штатной структуре представлены на рисунке 14.

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

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

Все структурные подразделения, занимающиеся разработкой, объединяются в Центр разработки. В том числе выделяется Управление развития инструментальных средств и Управление разработки прикладных систем. Первое подразделение занимается инструментарием для разработки прикладных систем, второе же – непосредственно разработкой прикладных систем. В состав Центра также входит Управление проектирования.

Все подразделения, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.

В состав Департамента системной интеграции включены подразделения, ответственные за техническую поддержку, ИТ-инфраструктуру, дизайн и рекламу.

Также отдельно выделен Департамент профессионального развития персонала.

Рисунок 14. Новая организационно-штатная структура

3.3 Регламентирование деятельности

Наиболее проблемные и неформализованные бизнес-процессы были регламентированы с целью максимально точного соответствия действий сотрудников компании оптимизированным бизнес-процессам.

Регламентированию подверглись в первую очередь следующие процессы:

-  Оперативный мониторинг и информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);

-  Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);

-  Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).

Регламенты являются определяющими документами при выполнении указанных процессов.

Помимо регламентов, были разработаны типовые должностные инструкции (образец приведен в Приложении 5), а также квалификационные требования к сотрудникам компании (образец приведен в Приложении 6), что позволит упорядочить и организовать процессы, связанные с движением кадров в компании.

3.4 Перспективные направления автоматизации

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

Приоритетными являются нижеуказанные направления.

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

-  учетные сведения о клиентах;

-  реестр контрактов;

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

Кадровый учет:

-  штатная структура компании;

-  личные карточки сотрудников;

-  приказы о назначении, увольнении, отпусках и пр.;

-  табельный учет.

Делопроизводство и документооборот:

-  входящая и исходящая корреспонденция;

-  создание, согласование и утверждение внутренней документации;

-  поддержка управления версиями документов.

Информационная поддержка процессов выпуска дистрибутивов и обновлений:

-  учет дистрибутивов и стадий их выпуска;

-  учет замечаний, реализованных в дистрибутиве;

-  учет разовых обновлений;

-  учет установленных у клиентов версий дистрибутивов.

Информационная поддержка процессов разработки, внедрения, сопровождения, технической поддержки:

-  планирование деятельности;

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

З аключение

Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.

Осуществлен переход от функционально-ориентированной к проектно-ориентированной штатной структуре компании.

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

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

Разработаны регламенты ключевых процессов: разработки, сопровождения, контроля.

Сформирован комплект образцов документации, создаваемой во время жизненного цикла проекта.

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

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

1.Амблер С. Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. СПб.: Питер, 2005.

2.Бек К. Экстремальное программирование. СПб.: Питер, 2002.

3.Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.

4.Даешь инжиниринг! М.: Издательство Эксмо, 2005.

5.Константайн Л., Локвуд Л. Разработка программного обеспечения. СПб.: Питер, 2004.

6.Крачтен, Филипп. Введение в Rational Unified Process. 2-е изд. М.: Издательский дом «Вильямс», 2002.

7.Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP. М.: КУДИЦ-ОБРАЗ, 2004.

8.Липунцов Ю.П. Управление процессами. Методы управления предприятием с использованием информационных технологий. М.: Компания АйТи, 2003.

9.Хэлдман Ким. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.

П риложение 1

Образцы внутренних документов

Структура документа «Постановка задачи»

Данный документ является уточняющим для документа «Техническое задание», составляется по каждой значимой функциональности и содержит более подробные описания бизнес-процессов, в т.ч. в нотации UML.

1.  Основные сведения

-  Название проекта, модуль

-  Название функциональности

-  Основания для разработки (контракт, пользователь, законодательство, и пр.)

-  Необходимость распространения на другие проекты

2.  Описание назначения

-  Описание функциональности, ссылки на законодательство и пр.

3.  Варианты использования

a.  Название варианта использования, текстовое описание, UML-схема

b.  Название варианта использования, текстовое описание, UML-схема

c.  …

4.  Диаграммы потоков данных

при необходимости

5.  Диаграммы переходов состояний

при необходимости

6.  Диаграммы классов

при необходимости

7.  Проект пользовательского интерфейса

8.  Ограничения

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

Структура документа «Заявка»

1.  Основные сведения

-  Номер заявки (из внутренней системы)

-  Название проекта, модуль

-  Основания для разработки

2.  Описание заявки

-  Текстовое описание содержания заявки, при необходимости – ссылки на скриншоты (для ошибок – обязательно)

3.  Скриншоты

-  копии экранов с выделенными и пронумерованными блоками (для ссылок в текстовом описании)

Структура документа «Тестовый пример»

1.  Основные сведения

-  Номер заявки (из внутренней системы)

-  Название проекта, модуль

-  Название функциональности

2.  Тестовые примеры

a.  Тест 1

o  Входные параметры: «название» = «значение»

o  Последовательность действий пользователя

o  Выходные параметры: «название» = «значение»

b.  Тест 2

o  Входные параметры: «название» = «значение»

o  Последовательность действий пользователя

o  Выходные параметры: «название» = «значение»

c.  …

Структура документа «Описание реализации»

1.  Основные сведения

-  Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

-  Название проекта, модуль

-  Название функциональности

2.  Описание алгоритма

-  Общее описание выбранных методов решения задачи

3.  Реализация вариантов использования (если были указаны в «Постановке задачи»)

a.  Название варианта использования, алгоритм реализации

b.  …

4.  Описание системных изменений

a.  перечень измененных системных объектов (процедур, функций, модулей и пр.), при этом в коде указанных объектов обязательны следующие комментарии:

o  дата создания, автор, назначение;

o  все входные и выходные параметры, а также используемые внутри переменные должны иметь описание назначения;

o  код должен быть разбит на логические блоки (при их наличии), снабженные комментариями об их назначении;

o  при каждом изменении в начале после описания назначения должен вставляться комментарий с датой, автором и описанием изменения.

b.  видимо, в основном для ИИС – перечень измененных классов, гридов, и пр.

5.  Описание интерфейсных изменений

при изменении форм – скриншоты «что было» - «что стало» с выделением изменений

при добавлении форм – скриншоты этих форм

6.  Диаграммы классов

при необходимости, видимо, в основном для ИИС

Структура документа «Краткое руководство»

Документ «Краткое руководство» составляется в свободном стиле, при этом он должен отражать описание всех вариантов использования, реализованных для требования.

Структура документа «Отчет о тестировании»

Данный документ составляется на основании «Программы и методики испытаний» либо «Тестового примера».

1.  Основные сведения

-  Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

-  Название проекта, модуль

-  Название функциональности

-  Дата тестирования, номер цикла тестирования

-  Суммарные данные (% успешно пройденных тестов)

2.  Тест 1: пройден/не пройден

-  Должно быть:

o  Входные параметры: «название» = «значение»

o  Последовательность действий пользователя

o  Выходные параметры: «название» = «значение»

-  Получено:

o  Выходные параметры: «название» = «значение»

-  Комментарии

3.  Тест 2: пройден/не пройден

-  …

4.  …

Структура документа «Ведомость замечаний»

«Ведомость замечаний» составляется в двух случаях:

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

2.  При внедрении и сопровождении системы.

Структура документа является следующей:

1.  Основные сведения

-  Название проекта

-  Дата составления, последовательный номер, автор

-  Ссылка на «Отчет о тестировании» либо период внедрения/сопровождения, за который получены указанные замечания

2.  Таблица замечаний

3.  Скриншоты

-  копии экранов с выделенными и пронумерованными блоками (для ссылок в комментариях)

Структура документа «Отчет об устранении замечаний»

1.  Основные сведения

-  Номер заявки (из внутренней системы) – в случае выполнения разовой заявки

-  Название проекта, модуль

-  Название функциональности

-  Дата составления, последовательный номер

2.  Таблица замечаний

Структура документа «Отчет об установке»

1.  Основные сведения

-  Номер обновления/дистрибутива (из внутренней системы)

-  Название организации

-  Дата установки, ФИО сотрудника, проводившего установку

-  При установке у пользователя – ФИО пользователя, должность, комната, телефон

2.  Сведения об ошибках в ходе установки

-  допустимо использование скриншотов

Структура документа «Ведомость обучения»

1.  Основные сведения

-  Название организации, проекта

-  ФИО сотрудника, проводившего обучение

2.  Ведомость обучения

П риложение 2

Регламент оперативного мониторинга и информационной поддержки хода исполнения контрактных обязательств

1.  Общие положения

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

1.2.  Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).

2.  Ответственность и состав информации

2.1.  Бухгалтерия организации является ответственной за ввод следующих данных:

-  адресные данные юридических лиц;

-  банковские реквизиты юридических лиц;

-  сведения о подготовке счетов, счетов-фактур;

-  сведения о поступлении оплаты по счетам.

2.2.  Помощник генерального директора является ответственным за ввод следующих сведений:

-  проекты контрактов и этапы в составе данных контрактов;

-  сведения о порядке и сроках оплаты этапов контрактов;

-  документы к контракту;

-  сведения об отправке и получении отчетных документов по этапам работ.

2.3.  Руководитель департамента/управления (либо заместитель руководителя) является ответственным за ввод следующих сведений:

-  содержание работ по этапам контрактов (для последующего планирования работ начальником отдела).

2.4.  Начальник отдела является ответственным за:

-  планирование работ по этапам контрактов;

-  контроль хода исполнения этапов;

-  формирование отчета о ходе исполнения контрактных обязательств.

3.  Регламент учета данных

3.1.  Начальник отдела (либо по его распоряжению – заместитель начальника отдела) обязан за 15 дней (если не указано иное) до окончания срока этапа обеспечить подготовку отчет о ходе исполнения этапа с перечислением всех работ, проводившихся в рамках данного этапа.

3.2.  Помощник генерального директора обязан за 15 дней (если не указано иное) до окончания срока этапа подготовить акт по данному этапу контракта.

3.3.  Бухгалтер обязан за 15 дней (если не указано иное) до окончания срока этапа подготовить счет на оплату работ по данному этапу контракта.

3.4.  Отчет, акт и счет на оплату работ прикрепляются к исходящему письму, регистрируются делопроизводителем и отправляются заказчику. В системе при этом автоматически отражаются сведения о сроках отправки документов.

3.5.  При возврате документов делопроизводитель отмечает срок подписания и возврата документов.

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

4.  Регламент оперативного мониторинга

4.1.  Ежедневно заместитель руководителя департамента и начальник отдела (либо по его распоряжению – заместитель начальника отдела) контролирует перечень активных задач по контрактным обязательствам и обеспечивает их оперативное выполнение.

4.2.  Еженедельно заместитель руководителя департамента и начальник отдела (либо по его распоряжению – заместитель начальника отдела) контролирует перечень этапов, по которым наступили сроки подготовки отчета о выполненных работах и при необходимости готовит либо дает поручение о подготовке указанных отчетов.

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

4.3.1.  Помощник генерального директора готовит акт о выполненных работах;

4.3.2.  Начальник отдела (либо по его указанию – заместитель начальника отдела), ответственного за выполнение данных работ, готовит отчет о проделанных работах;

4.3.3.  Бухгалтер готовит счет на оплату работ.

4.4.  После отправки документов помощник генерального директора еженедельно контролирует сроки подписания и возврата документов.

4.5.  После возврата документов бухгалтер ежедневно контролирует поступление оплаты по подписанным счетам.

П риложение 3

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

1.  Общие положения

1.1.  Данный документ описывает внутренний порядок разработки программного обеспечения и выпуска дистрибутивов для установки у заказчиков.

1.2.  Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).

2.  Основные участники регламента

2.1.  Основными участниками данного регламента являются:

-  руководитель проекта;

-  ответственные руководители структурных подразделений;

-  аналитик;

-  разработчик;

-  специалист по тестированию;

-  технический писатель.

3.  Регламент регистрации заявки

3.1.  Руководитель проекта обязан обеспечить регистрацию в системе всех заявок на разработку по соответствующим проектам.

3.2.  При регистрации заявки руководитель проекта обязан обеспечить ввод следующих сведений:

-  проект;

-  реализация в рамках проекта;

-  организация;

-  в рамках какого этапа контракта выполняется работа;

-  содержание работы;

-  плановые сроки выполнения работы;

-  срочность Заказчика;

-  приоритет работы;

-  вид базы данных (SQL, ORACLE, SQL+ORACLE);

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

3.3.  При сохранении заявки система должна обеспечить автоматическое присвоение номера заявки.

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

-  пример базы данных;

-  шаги воспроизведения.

3.5.  Для инициирования процесса обработки заявки руководитель проекта должен:

-  перевести задачу на исполнение аналитикам;

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

4.  Регламент анализа постановки задачи

4.1.  Руководитель (либо заместитель руководителя) соответствующего подразделения (Управление системных проектов) при поступлении заявки обязан:

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

4.1.2.  включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения.

4.2.  Исполнитель (аналитик) проводит работы по систематизации документов, относящихся к постановке задачи и приложенных руководителем проекта.

4.3.  Результатом работы аналитика должен быть документ «Постановка задачи», отражающий полное и всестороннее описание работ, указанных в заявке. Данный документ должен использоваться для проведения разработки, тестирования и документирования и является основополагающим.

4.4.  Для инициирования процесса разработки аналитик должен отразить в системе завершение стадии постановки задачи. После этого действия заявка переходит в Центр Разработки.

4.5.  В случае невозможности разработки «Постановки задачи» аналитик обязан перенаправить заявку руководителю проекта, фиксируя момент и причины перенаправления в системе.

5.  Регламент исполнения заявки Центром разработки

5.1.  Руководитель (либо заместитель руководителя) Центра разработки при поступлении заявки обязан определить ответственное подразделение в составе Центра разработки и передать заявку соответствующему руководителю, зафиксировав момент передачи в системе.

5.2.  Руководитель (либо заместитель руководителя) ответственного подразделения Центра разработки обязан:

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

5.2.2.  определить область действия заявки (проекты, в которых реализована указанная функциональность, либо все проекты);

5.2.3.  включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения.

5.3.  Сотрудник Центра разработки при поступлении заявки к исполнению обязан:

5.3.1.  предпринять все необходимые меры для устранения в срок указанных в «Постановке задачи» проблем для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE);

5.3.2.  обеспечить ввод в систему сведений о фактически проведенных работах по устранению указанных в «Постановке задачи» проблем.

5.4.  В случае устранения проблемы сотрудник Центра разработки обязан:

5.4.1.  отметить в системе дистрибутив, в состав которого войдет выполненная заявка для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE);

5.4.2.  приложить «Список измененных модулей», в котором явно отразить участки, подлежащие тестированию для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE)

5.4.3.  при необходимости ввести уточняющие «Постановку задачи» сведения по порядку документирования выполненной заявки;

5.4.4.  отразить в системе завершение стадии разработки задачи.

5.5.  В случае невозможности разработки сотрудник Центра разработки обязан перенаправить заявку руководителю своего структурного подразделения, фиксируя момент и причины перенаправления в системе.

5.6.  При завершении стадии разработки руководитель (либо заместитель руководителя) Центра разработки переводит заявку в статус тестирования и назначает специалиста, ответственного за тестирование.

6.  Регламент тестирования

6.1.  Специалист, ответственный за тестирование, изучает «Постановку задачи», «Список измененных модулей», разрабатывает и вносит в систему «Методику тестирования», после чего проводит тестирование по написанной методике.

6.2.  По завершении тестирования специалист, ответственный за тестирование, формирует и вносит в систему «Отчет о тестировании» для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).

6.3.  В случае успешного выполнения тестирования специалист, ответственный за тестирование, отмечает в системе завершение тестирования. После этого заявка переходит в статус документирования.

6.4.  В случае обнаружения ошибок в процессе тестирования специалист, ответственный за тестирование, возвращает заявку на доработку в Центр разработки.

7.  Регламент документирования изменений

7.1.  Руководитель (либо заместитель руководителя) подразделения, ответственного за документационное обеспечение, при поступлении заявки на документирование назначает ответственного специалиста по документированию.

7.2.  Специалист по документированию на основании представленных материалов обновляет документацию, необходимую для выпуска соответствующего дистрибутива (руководство пользователя, руководство администратора, список изменений в дистрибутиве и пр.) для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).

7.3.  После завершения документирования специалист по документированию отмечает в системе завершение документирования, и заявка в системе перенаправляется руководителю проекта.

8.  Регламент закрытия заявки

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

8.2.  В случае наличия замечаний руководитель проекта вносит в систему сведения о необходимых доработках. С этого момента заявка считается вновь принятой в систему.

9.  Регламент формирования дистрибутива

Определения

Рабочая версия – полный набор файлов приложения, предназначенных для включения в дистрибутив, доступный разработчикам на внесение изменений.

Сборка – пронумерованная отложенная версия установочного exe-файла, доступная на чтение разработчикам, специалистам по тестированию и специалистам по документированию

Дистрибутив – успешно прошедшая тестирование и документирование сборка, оформленная в виде пронумерованного установочного exe-файла с учетом исправленных файлов приложения на этапе тестирования, готовая к установке у заказчиков.

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

Порядок формирования дистрибутива

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

9.2.  В течение 2-х недель с момента утверждения состава новой версии дистрибутива производится разработка в соответствии с настоящим Регламентом. По окончании разработки выпускается новая сборка и сопутствующий ей перечень фактически проведенных изменений (выполненных заявок). Данной сборке присваивается номер.

9.3.  В течение 2-х недель с момента выпуска новой сборки производится ее тестирование, доработка и документирование. Доработка производится в рамках фактически проведенных изменений на момент сборки (новый функционал не добавляется).

9.4.  По окончании тестирования, доработки и документирования выпускается новый дистрибутив и перечень фактических изменений к нему. Из состава дистрибутива исключаются те заявки, доработка которых не была завершена к моменту его выпуска. Дистрибутиву присваивается номер.

9.5.  С момента выпуска дистрибутива цикл разработки новых версий повторяется с п.9.1 настоящего Регламента.

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

П риложение 4

Регламент исполнения заявок на обслуживание и сопровождение

1.  Общие положения

1.1.  Данный документ описывает порядок обработки информации о поступающих заявках на обслуживание и сопровождение.

1.2.  Информационная поддержка указанных процессов осуществляется с использованием внутренней автоматизированной информационной системы (далее - система).

2.  Основные участники регламента

2.1.  Основными участниками данного регламента являются:

-  ответственные руководители;

-  специалист-диспетчер;

-  разработчик;

-  технический писатель;

-  специалист по тестированию;

-  специалист по внедрению и сопровождению;

-  специалист технической поддержки.

3.  Регламент регистрации заявок

3.1.  Заявки по телефону обязан принимать специалист-диспетчер.

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

3.3.  При поступлении заявки по телефону либо электронной почте специалист-диспетчер обязан зарегистрировать заявку в системе, указав следующие сведения:

-  способ поступления заявки (звонок, электронная почта, и пр.);

-  организация и контактное лицо;

-  содержание заявки;

-  срочность Заказчика;

-  на кого перенаправлена заявка.

3.4.  Система автоматически фиксирует номер поступившей заявки и статус «постановка задачи».

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

3.6.  В случае адресного обращения к сотрудникам сопровождения и технической поддержки (в частности, по мобильному телефону) либо при поступлении заявки через журнал сотрудник должен обеспечить максимально оперативный ввод заявки в систему, заполнив следующие сведения:

-  способ поступления заявки (звонок, электронная почта, и пр.);

-  проект;

-  реализация в рамках проекта (для заявок на сопровождение ПО);

-  организация и контактное лицо;

-  срочность Заказчика;

-  содержание заявки;

-  вид базы данных (SQL, ORACLE, SQL+ORACLE);

-  шаги воспроизведения.

3.7.  Заявка, введенная сотрудником сопровождения или технической поддержки, поступает на утверждение непосредственному руководителю сотрудника. Дальнейшая обработка заявки производится в соответствии с разделом 5 настоящего Регламента.

4.  Регламент обеспечения «горячей линии»

4.1.  Специалист «горячей линии» обязан выяснить у пользователя подробности заявки, в т.ч. последовательность действий, приводящую к возникновению проблемы, и заполнить в системе недостающие сведения.

4.2.  Специалист «горячей линии» обязан попытаться определить причину и возможность оперативного устранения проблемы. При наличии такой возможности специалист «горячей линии» консультирует пользователя по телефону (либо по электронной почте) и фиксирует содержание консультации в системе по конкретной заявке.

4.3.  В случае устранения проблемы специалист «горячей линии» обязан отметить в системе заявку как выполненную. Заявка при этом переходит в статус «выполнена горячей линией».

4.4.  В случае если содержание заявки относится к задачам, реализованным на разных базах данных (SQL, ORACLE, SQL+ORACLE), то проблема устраняется для каждой из баз данных;

4.5.  В случае невозможности устранения проблемы специалист «горячей линии» обязан сообщить пользователю о том, что его заявка принята к дальнейшей обработке, и перенаправить заявку руководителю соответствующего проекта, фиксируя момент и причины перенаправления в системе, указывая необходимость устранения для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).

5.  Регламент исполнения заявки в рамках сопровождения

5.1.  Руководитель соответствующего проекта при поступлении заявки обязан определить степень сложности проблемы:

5.2.  Руководитель либо заместитель руководителя ответственного подразделения Управления обязан:

5.2.1.  рассмотреть заявку;

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

5.2.3.  в случае невозможности устранения проблемы сотрудником сопровождения перенаправить заявку в Центр разработки, указав в системе момент и причины перенаправления. Дальнейшая обработка заявки происходит в соответствии с Регламентом учета и выполнения заявок на разработку.

5.2.4.  в случае возможности устранения проблемы сотрудником сопровождения включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения; заявка при этом переходит в статус «исполняется сопровождением».

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

5.4.  В случае устранения проблемы сотрудник сопровождения обязан отразить в системе завершение стадии исполнения заявки.

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

5.6.  При завершении стадии исполнения руководитель проекта переводит заявку в статус тестирования и назначает специалиста, ответственного за тестирование.

6.  Регламент тестирования

6.1.  Специалист, ответственный за тестирование, изучает материалы заявки и вносит в систему «Методику тестирования», после чего проводит тестирование по написанной методике.

6.2.  По завершении тестирования специалист, ответственный за тестирование, формирует и вносит в систему «Отчет о тестировании».

6.3.  В случае успешного выполнения тестирования специалист, ответственный за тестирование, отмечает в системе завершение тестирования для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE). После этого заявка переходит в статус документирования.

6.4.  В случае обнаружения ошибок в процессе тестирования специалист, ответственный за тестирование, возвращает заявку на доработку руководителю проекта.

7.  Регламент документирования изменений

7.1.  Руководитель (либо заместитель руководителя) подразделения, ответственного за документационное обеспечение, при поступлении заявки на документирование назначает ответственного специалиста по документированию.

7.2.  Специалист по документированию на основании представленных материалов обновляет документацию, необходимую для документирования выполнения соответствующей заявки (руководство пользователя, руководство администратора и пр.) для всех требуемых баз данных (SQL, ORACLE, SQL+ORACLE).

7.3.  После завершения документирования специалист по документированию отмечает в системе завершение документирования, и заявка в системе перенаправляется руководителю проекта.

8.  Регламент закрытия заявки или возврата на доработку

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

8.2.  В случае наличия замечаний руководитель проекта вносит в систему сведения о необходимых доработках. С этого момента заявка считается вновь принятой в систему.

9.  Регламент исполнения заявки в рамках технической поддержки

9.1.  Заместитель руководителя Управления системной интеграции при поступлении заявки обязан определить ответственное подразделение в составе Управления и передать заявку соответствующему руководителю, зафиксировав момент передачи в системе.

9.2.  Руководитель либо заместитель руководителя ответственного подразделения Управления обязан:

9.2.1.  рассмотреть заявку;

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

9.2.3.  включить заявку в перспективный либо оперативный план работы подразделения и назначить исполнителя, сроки устранения; заявка при этом переходит в статус «исполняется технической поддержкой».

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

9.4.  В случае устранения проблемы содни Управления обязан отметить в системе заявку как выполненную.

9.5.  В случае невозможности устранения проблемы сотрудник Управления обязан перенаправить заявку руководителю своего структурного подразделения, фиксируя момент и причины перенаправления в системе.

Приложение 5

Типовая должностная инструкция специалиста-стажера Управления разработки прикладных систем

1.  Общие положения

1.1.  Специалист-стажер Управления разработки прикладных систем (далее – специалист-стажер) относится к категории рядовых сотрудников организации.

1.2.  Настоящая должностная инструкция составлена на основании действующего законодательства Российской Федерации, Устава организации, Правил внутреннего трудового распорядка организации, Положения об Управлении разработки прикладных систем (далее - Управление).

1.3.  Специалист-стажер назначается на должность или увольняется Генеральным директором по представлению начальника Управления и по согласованию с руководителем Центра разработки.

1.4.  Специалист-стажер подчиняется непосредственно начальнику Управления.

2.  Квалификационные требования

2.1.  Специалист-стажер должен иметь высшее либо незаконченное высшее профессиональное образование.

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

3.  Должностные обязанности

3.1.  В соответствии с основными функциями Департамента и отдела специалист-стажер исполняет следующие должностные обязанности:

3.1.1.  Организация и реализация технологического процесса:

-  Разработка пользовательских форм представления информации;

-  Разработка экранных отчётов и выходных форм;

-  Подготовка предварительных материалов для эксплуатационной документации;

-  Модульное тестирование;

-  Интегральное тестирование;

-  Регрессионное тестирование;

-  Системное тестирование;

-  Тестирование удобства и простоты пользования;

-  Формирование отчёта о проведении тестирования.

3.1.2.  Исполнение административных функций:

-  Периодическое ознакомление с обучающими материалами;

-  Периодическое прохождение тестирования и аттестации.

3.2.  В своей деятельности специалист-стажер обязан:

-  неукоснительно выполнять и применять в практической работе нормативно-правовые акты и документы в сфере своей деятельности;

-  соблюдать правила внутреннего трудового распорядка;

-  поддерживать уровень квалификации, достаточный для исполнения своих должностных обязанностей;

-  хранить государственную и иную охраняемую законом тайну.

4.  Должностные полномочия

4.1.  Специалист-стажер имеет право на:

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

-  использование в служебных целях имеющихся в отделе компьютерных и иных технических средств;

-  визирование служебной документации в пределах своей компетенции;

-  другие права, предусмотренные Трудовым кодексом Российской Федерации.

5.  Ответственность

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

5.2.  Специалист-стажер несет материальную ответственность за переданные ему компьютерные и иные технические средства в порядке, установленном Трудовым кодексом Российской Федерации.

П риложение 6

Таблица. Типовые квалификационные требования к сотрудникам Управления разработки прикладных систем