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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.  Начальник отдела (либо по его указанию – заместитель начальника отдела), ответственного за выполнение данных работ, готовит отчет о проделанных работах;

Страницы: 1, 2, 3, 4, 5, 6, 7, 8