Моделирование бизнес-процессов на примере компании-разработчика программного обеспечения (стр. 8 из 12)
Документирование процесса перехода между стадиями
Для каждой стадии должны быть определены результирующие документы для передачи продукта на следующую стадию (Рисунок 13). В этом случае процесс передачи и последующего взаимодействия будет упорядоченным, управляемым и отслеживаемым.
Рисунок 13. Документирование процесса перехода между стадиями
Если у исполнителей следующей стадии есть замечания к результатам предыдущей стадии, они обязательно оформляются документально в виде ведомости замечаний и передаются лицу, ответственному за предыдущую стадию. Исправление замечаний может выполняться на этой же итерации (приводит к сдвигу сроков либо сокращению объемов работ следующих стадий данной итерации), либо может быть перенесено на следующую итерацию (следует проверить необходимость сдвига сроков в общем плане итераций).
Исправления, вносимые по результатам замечаний, также должны оформляться документально в виде протокола устранения замечаний.
Если исправления вносятся на текущей стадии:
- увеличивается срок предыдущей стадии в связи с необходимостью исправления замечаний;
- возможно, увеличивается срок текущей стадии (в связи с изменением объема работ, в связи с необходимостью ожидания исправлений).
Образцы и краткое содержание документов, указанных на рисунке, приведены в Приложении 1.
Процесс перехода между итерациями
После завершения каждой итерации должен обеспечиваться выпуск очередной версии продукта с определенным объемом функциональности. Достигнутый объем функциональности определяется в соответствии с выполненными работами из первоначального плана.
В результате завершения итерации в хранилище данных по проекту, доступном всем заинтересованным лицам, должны находиться следующие данные:
- пронумерованная версия продукта (библиотеки, исполняемые файлы, база данных и пр.);
- описание функциональности, добавленной по сравнению с предыдущей версией;
- пронумерованные версии всех проектных документов на момент завершения итерации.
Желательно обеспечить сбор статистических данных по количеству взаимодействий на различных стадиях итерации и в различных зонах для последующей оценки результатов.
Процесс перехода продукта из разработки во внедрение и сопровождение
При передаче продукта из разработки во внедрение и дальнейшее сопровождение руководитель проекта (при его отсутствии – руководитель подразделения, ответственного за внедрение) составляет план внутренней приемки продукта, в котором должны быть отражены следующие этапы:
- ознакомление с проектной документацией;
- демонстрация программного продукта;
- обучение сотрудников внедрения работе с продуктом.
Все замечания к продукту, выявленные на данных этапах, классифицируются, и либо устраняются путем проведения еще одной итерации доработки продукта, либо включаются в план разработки следующей версии продукта.
Оценка деятельности
Качество продукта, выпускаемого после каждой стадии, приблизительно можно определить после завершения итерации по собранным статистическим данным.
Большое количество документов «Уведомление об изменении требований» свидетельствует о недостаточной проработке соответствующих вопросов во время выполнения стадии, и, соответственно, о низком качестве работы исполнителей.
Документ «Ведомость замечаний» свидетельствует о наличии вопросов и замечаний со стороны исполнителей какой-либо стадии к результатам предыдущей стадии. Чаще всего это также свидетельствует о низком качестве результатов, реже – о недостаточной квалификации исполнителей текущей стадии.
Влияние данных документов на конечный результат можно оценить с помощью зоны, в которую попадали документы: зеленая зона – незначительное влияние, оранжевая зона – среднее влияние, красная зона – значительное влияние, черная зона – очень серьезное влияние.
Данные документы должны строго отслеживаться руководителем проекта и руководителями соответствующих структурных подразделений для оперативного определения проблемных участков проекта.
3.2 Изменения в организационно-штатной структуре
Изменения в организационно-штатной структуре представлены на рисунке 14.
Для обеспечения перехода к проектному управлению необходимо осуществить изменения в организационно-штатной структуре. Ключевым изменением является выделение руководителей проекта, непосредственно подчиняющихся генеральному директору/заместителю генерального директора, что позволит постепенно осуществлять переход к проектно-ориентированной структуре организации. Ресурсы для каждого проекта должны подбираться из соответствующих структурных подразделений под контролем линейных руководителей, однако после выделения ресурса на проект основным руководителем становится руководитель проекта – до момента окончания участия данного сотрудника в проекте. После этого сотрудник возвращается в пул доступных ресурсов в рамках своего подразделения.
В целях организации качественного процесса анализа необходимо выделение Аналитического департамента, в состав которого включается как Аналитический отдел, так и Отдел документационного обеспечения.
Все структурные подразделения, занимающиеся разработкой, объединяются в Центр разработки. В том числе выделяется Управление развития инструментальных средств и Управление разработки прикладных систем. Первое подразделение занимается инструментарием для разработки прикладных систем, второе же – непосредственно разработкой прикладных систем. В состав Центра также входит Управление проектирования.
Все подразделения, ответственные за внедрение и сопровождение, объединяются в Департамент сопровождения.
В состав Департамента системной интеграции включены подразделения, ответственные за техническую поддержку, ИТ-инфраструктуру, дизайн и рекламу.
Также отдельно выделен Департамент профессионального развития персонала.
Рисунок 14. Новая организационно-штатная структура
3.3 Регламентирование деятельности
Наиболее проблемные и неформализованные бизнес-процессы были регламентированы с целью максимально точного соответствия действий сотрудников компании оптимизированным бизнес-процессам.
Регламентированию подверглись в первую очередь следующие процессы:
- Оперативный мониторинг и информационная поддержка хода исполнения контрактных обязательств (Регламент приведен в Приложении 2);
- Разработка программного обеспечения и выпуск дистрибутивов (Регламент приведен в Приложении 3);
- Исполнение заявок на обслуживание и сопровождение (Регламент приведен в Приложении 4).
Регламенты являются определяющими документами при выполнении указанных процессов.
Помимо регламентов, были разработаны типовые должностные инструкции (образец приведен в Приложении 5), а также квалификационные требования к сотрудникам компании (образец приведен в Приложении 6), что позволит упорядочить и организовать процессы, связанные с движением кадров в компании.
3.4 Перспективные направления автоматизации
В ходе анализа деятельности компании выявлен ряд направлений, перспективных с точки зрения последующей автоматизации. Так как компания сама является разработчиком программного обеспечения и заинтересована в разработке комплексных решений по управлению предприятием, оптимальным решением будет разработка собственной системы.
Приоритетными являются нижеуказанные направления.
Информационная поддержка исполнения контрактных обязательств:
- учетные сведения о клиентах;
- реестр контрактов;
- документационное обеспечение контрактных обязательств (контракты, дополнительные соглашения, календарные планы, акты, счета, отчеты и прочая документация).
Кадровый учет:
- штатная структура компании;
- личные карточки сотрудников;
- приказы о назначении, увольнении, отпусках и пр.;
- табельный учет.
Делопроизводство и документооборот:
- входящая и исходящая корреспонденция;
- создание, согласование и утверждение внутренней документации;
- поддержка управления версиями документов.
Информационная поддержка процессов выпуска дистрибутивов и обновлений:
- учет дистрибутивов и стадий их выпуска;
- учет замечаний, реализованных в дистрибутиве;
- учет разовых обновлений;
- учет установленных у клиентов версий дистрибутивов.
Информационная поддержка процессов разработки, внедрения, сопровождения, технической поддержки:
- планирование деятельности;
- учет и отслеживание хода выполнения задач и заявок пользователей, оперативных поручений руководства.
Заключение
Поставленная задача оптимизации бизнес-процессов была решена в полном объеме; оптимизации подверглись основные процессы деятельности организации, а именно разработка, внедрение и сопровождение программного обеспечения.
Осуществлен переход от функционально-ориентированной к проектно-ориентированной штатной структуре компании.
В результате анализа наиболее удобным типом процесса разработки для новых проектов признан унифицированный процесс, для проектов по сопровождению – инкрементальный процесс.