Автор работы: Пользователь скрыл имя, 09 Марта 2012 в 22:46, курсовая работа
В ИТ - проектах заняты миллионы программистов и аналитиков, руководителей разного ранга и простых инженеров по всему миру. Процесс создания программного обеспечения стал технологией, где у каждого члена проектной команды определено своё место и круг обязанностей, где строго регламентированы все этапы – от замысла до передачи Заказчику рабочей версии программы с документацией.
Введение 2
1. Понятие процесса и процессного подхода 3
2. Классификация процессов 5
3. Ролевая модель процесса 5
4. Зрелость процесса 6
5. Жизненный цикл процесса 6
6. Идентификация процесса 7
7. Проектирование процесса 8
7.1 Диаграмма потоков данных 9
7.2 Кросс - функциональная диаграмма 9
7.3 ARIS 9
7.3.1. ARIS.VAD/VACD 9
7.3.2. ARIS.FAD 9
7.3.3. ARIS.eEPC 9
7.4 Структура регламентов 9
7.5 Оптимизация процессов 9
7.5.1 Удаление действий, не добавляющих ценность 9
7.5.2 Параллельное выполнение работ 9
7.5.3 Устранение временных разрывов 9
7.5.4 Расшивка узких мест 9
7.5.5 Участие вместо контроля 9
7.5.6 Разработка вариантов процесса 10
Уровень зрелости нашего процесса оценивается, как 4 уровень зрелости, по итогам представленной матрицы.
ЭТАП | НОМЕР ШАГА | ||||||
1 | 2 | 3 | 4 | 5 | 6 | 7 | |
Инициирование | + | + | + | + | + | + | + |
Проектирование | + | + | + | + | + | + |
|
Внедрение | + | + | + | + |
|
|
|
Осуществление, измерение, анализ | + | + | + | + | + | + |
|
Ликвидация | + | + |
|
|
|
|
|
Вывод: после применения концепции жизненного цикла, процесса к
определенного ранее процессу, отличий между полученной и «оригинальной»
модели не выявлено.
Наименование процесса: | Процесс разработки и внедрения ПО (для внутреннего заказчика) |
Границы процесса и контекст процесса:
| Момент начала: от отдела бизнес - анализа поступило ТЗ, в формате бизнес требований; Момент окончания: система готова и установлена, соответствует требованиям, и пользователи работают с ней (произведено финальное тестирование, обучение персонала, опытная эксплуатация); На входе: бизнес - требования; На выходе: система в промышленной эксплуатации. |
Контекст – подразделение, деятельность которую автоматизируем. | |
Ролевая модель процесса:
| Потребитель процесса: руководитель подразделения; Пользователь процесса: сотрудники подразделения; Заказчик процесса: руководитель подразделения; Поставщик процесса: поставщики средств разработки ПО, поставщики техники, поставщики и разработчики технологий; Владелец процесса: руководитель департамента разработки. |
Цель процесса, измерители, целевые показатели и допуски:
| Цель: Экономический эффект от использования ПО, в том подразделении, деятельность которого автоматизируется. Целевые показатели: Цель заказчика - уменьшение затрат за счет автоматизации бизнес процесса; Цель потребителя- уменьшение затрат за счет автоматизации бизнес процесса; Цель пользователя – уменьшение ошибок в работе за эргономичного интерфейса пользователя. Измерители и допуски: Уменьшение затрат; Уменьшение числа ошибок после внедрения, сравниваем со статистикой прошлых периодов, получаем отношения; Измеряем автоматизированный участок до и после внедрения ПО, получаем отношение, измеряемое в деньгах, процентах, чел\час, достигается за срок в 3 месяца. |
Результат процесса, в т. ч. требования к нему: | Программный продукт, повышающий экономическую эффективность подразделений. |
Для идентифицированного ранее процесса определили ролевую модель
группы проектирования в терминах ролей процесса и конкретных
должностей.
Владелец: директор по развитию; Консультант: эксперт по методологиям разработки ПО; Аудитор: внешний консультант по процессному управлению; Руководитель: руководитель департамента разработки. | Потребитель: руководитель департамента разработки; Заказчик: руководитель департамента разработки; Пользователь: руководитель направления, архитектор, программисты, аналитики и тестировщики. Информируемый: директор по развитию | |
Поставщики: по методологии разработки ПО методологии процессному управления. | Проектирование | |
Администратор ресурсов: Руководитель департамента разработки и директор по развитию; Владелец ресурсов: Руководитель департамента разработки и директор по развитию; Исполнители: Руководитель департамента разработки, архитектор, аналитики и специалисты по процессному управлению. | ||
Выделились совместимые роли:
администратор ресурсов и владелец ресурсов в нашей модели является
одним и тем же лицом (руководитель департамента разработки и
директор по развитию);
потребитель и заказчик в нашей модели является одним и тем же
лицом (руководитель департамента разработки).
Разработана диаграмма потоков данных (0-1 уровень декомпозиции) для
выбранного ранее процесса.
1. Лекции «Управление процессами – основа эффективности организации» - В.Е. Сирота.
2. ГОСТ 19781-90 «Обеспечение систем обработки информации»
7
11
Информация о работе Оптимизация бизнес-процессов оказания медицинских услуг