- •Часть 2. Годин в.В., Корнеев и.К. Управление информационными ресурсами: 17-модульная программа для менеджеров «Управление развитием организации». Модуль 17. – м.: инфра-м, 2000. – 352 с. 25
- •Часть 3. Тютюник а.В., Шевелев а.С. Информационные технологии в банке – м.: Издательская группа «бдц-пресс», 2003. – 368 с. 49
- •Часть 4. Баронов в.В. Автоматизация управления предприятием.– м.: инфра-м, 2000. – 239 с. 82
- •Часть 5. Case study 92
- •Часть 1. Аглицкий д.С., Аглицкий и.С. Рынок информационных технологий: проблемы и решения. – м.:2000
- •Глава 1
- •Подходы к автоматизации
- •Место и роль предприятия в обществе
- •Стратегия информатизации предприятия
- •Комплексно или по частям?
- •Купить или сделать?
- •Купить и доделать!
- •Принципы оценки экономической эффективности
- •Время и деньги
- •Глава 2 информационные технологии и консалтинг
- •Консультант на предприятии: бремя или благо
- •«Врачи» и «шарлатаны»
- •Роль и место консультанта
- •Виды работ и оплата труда
- •Выбор системы с участием консультантов
- •Выбор системы без участия консультантов
- •Консультирует компьютер
- •Глава 3 социально-психологические аспекты автоматизации
- •Инерционность руководства
- •Самодостаточность
- •Низкая квалификация персонала
- •Пиратство
- •Недоверие к тиражным системам
- •Глава 4 экономическая ЭффЕктивность автоматизации предприятий
- •Что такое экономическая эффективность автоматизации?
- •Расчет абсолютной эффективности
- •Учет фактора времени
- •Учет фактора неопределенности
- •Сравнение вариантов автоматизации
- •Типы информационных систем. Эволюция информационных систем
- •Глава 2 Каков должен быть уровень централизации обработки информации?
- •Глава 3 Создание информационных систем Планирование информационных систем
- •Стадии и этапы создания информационных систем и технологий с позиции руководства организации
- •Жизненный цикл информационных систем. Взгляд разработчика на создание информационной системы
- •Роль заказчика в создании информационной системы
- •Использование типовых проектных решений
- •Рынок информационных систем и тенденции его развития
- •Отдельные вопросы построения информационных систем и технологий
- •Глава 4 Стоимость информационной системы
- •Глава 5 Качество и эффективность информационных систем Эффективность информационных систем
- •Проблемы качества информационных систем и технологий
- •Минимальный перечень требований к системе, претендующей на «звание» корпоративной информационной системы
- •1. Функциональная полнота системы:
- •8. Наличие специальных средств анализа состояния системы в процессе эксплуатации:
- •Проведение тендера
- •Заключение контракта
- •Глава 2 Управление ит-персоналом
- •Особенности управления ит-персоналом
- •Элементы системы управления персоналом
- •Типовые роли
- •Риски персонала и совмещение
- •Мотивация и стимулирование
- •Глава 3 Обслуживание пользователей
- •Принципы поддержки пользователей
- •Технологическая схема работы
- •Типы запросов и приоритезация
- •База данных запросов и автоматизация
- •Отчетность и контроль
- •Глава 4 Управление аутсорсингом
- •Роль аутсорсинга в ит
- •Взаимодействие с внешними поставщиками
- •Риски аутсорсинга
- •Глава 5 Организация проекта
- •Проектная работа
- •Первичный анализ проекта
- •Создание проектной команды
- •Предпроектное обследование
- •Составление плана работ
- •Детальная постановка задачи
- •Взаимодействие с руководством
- •Глава 6 Разработка решений
- •Документирование
- •Исходные коды
- •Ответственность заказчика
- •Оценка эффективности разработки
- •Стадии разработки
- •Глава 7 Тестирование систем
- •Методы и подходы тестирования
- •Проблемы тестирования
- •Глава 8 Внедрение систем
- •Особенности внедрения
- •Организационные действия
- •Подготовка к внедрению
- •Начало рабочей эксплуатации
- •Завершение проектов
- •Глава 9 Анализ рисков при реализации проектов
- •Типы рисков в информационном проекте
- •Идентификация рисков
- •Снижение потерь
- •Некоторые рекомендации по выбору системы
- •5. Организация проекта
- •Глава 2 управление процессом внедрения и эксплуатации Типовой план внедрения
- •1. Предварительное обследование и оценка состояния
- •2. Предварительная переподготовка
- •3. Техническое задание
- •6. Выработка целей
- •7. Тз на управление процессами
- •8. Начальная переподготовка
- •9. Планирование и управление верхнего уровня
- •10. Управление данными
- •11. Одновременное внедрение различных технологий организа- ции и управления
- •12. Программное обеспечение (по)
- •13. Опытный пример
- •14. Получение результатов
- •15. Анализ текущего состояния
- •16. Постоянная переподготовка
- •Сопровождение и доработка системы
- •Вывод из эксплуатации и замещение новой системой
- •Часть 5. Case study case 1.Автоматизация страховой компании "Вест".
- •Case 2.Автоматизация промышленного предприятия "Фотон".
- •Case 3.Автоматизация торговой сети "Креон".
- •Case 4.Автоматизация внутреннего учета в коммерческом банке "Коломенский".
- •Case 5.Автоматизация издательской компании "Курсив".
Детальная постановка задачи
Следующий этап — детальная постановка задачи. Корректная по- становка задачи — уже повышение вероятности успеха и сокращение затрат на проект на 30 — 50%. Четкие ответы на вопрос «Что надо?» ча- сто сразу дают ответ на вопрос «Как делать?». Особенностью россий- ских правил учета является тот факт, что изменения в них часто носят весьма глобальный характер, в результате четкого понимания всех из- менений на этапе начала проекта нет ни у кого в организации. Для ре- шения этой проблемы используются приемы, которые рассмотрены ниже.
Описание глобальной цели проекта включает ответы на вопросы «Зачем?» как для внешней среды (Зачем ЦБ РФ издал такую инструк- цию?), так и самой организации и ее подразделений (Зачем организа- ции реализовывать этот проект?). Вариантов ответов на последний вопрос может быть несколько: «Чтобы организацию не оштрафовали» (са- мый неудачный ответ), «Данная инструкция позволит снизить операци- онные риски от совершения операций» и т.д. Анализ ответов позволит не только более точно понимать детали изменений, но и прогнозиро- вать дальнейшие дополнения и исправления.
Создание единого информационного пространства проекта. В простейшем варианте оно представляет собой директорию, в кото- рой все участники проекта записывают имеющуюся у них информацию и соображения по поводу решаемой задачи. Более сложным вариан- том является организация интранет-конференции.
Использование ролевого моделирования процесса подразуме- вает обыгрывание несколько раз бизнес-процесса всеми его участни- ками с обязательной регистрацией всех выполняемых действий и поже- лании:
Сотрудник
отдел
отчетности
Я
формирую
отчет
группировки
платежей
по
статьям
расхода
за
период.
В качестве
параметра
отчета
я
должен
определять
интервал
дат.
Отчет
должен
иметь
следующую
форму:
Данный прием моделирования позволяет максимально использовать имеющийся человеческий капитал, поскольку каждый участник строит свой бизнес-процесс самостоятельно, а общий контроль осуществляет руководитель и представители других подразделений.
Описанные приемы помогут группе более точно понять и написать техническое и бизнес-задание проекта. В бизнес-задании описываются основные функциональные требования, техническое — отражает бо- лее детальную информацию, особенности, включая параметры и под- ходы к реализации. Иногда они подготавливаются разными людьми, но гораздо чаще представляют единый документ, который готовится од- ним человеком — аналитиком. Далее мы не будем делать различий меж- ду этими документами и понятиями.
Следует помнить, что, если точного задания не получится, придется давать системе, реализующей проект, дополнительную гибкость. Но ре- ализация универсальной, гибкой бизнес-функции требует в несколько раз больше ресурсов на разработку и сопровождение, чем статичное решение.
Кроме того, рекомендуется вести разработку двух заданий, кото- рые условно можно назвать: «Программа-минимум» и «Программа- максимум». В первом варианте нужно описать минимальные измене- ния в организации по сравнению с текущим положением дел, доста- точные для реализации основной цели. Второй документ должен составляться с учетом всех пожеланий и перспектив. Как правило, в конце проекта будет реализован некоторый промежуточный вариант. Имея установленный проект бюджета, группа сначала реализует толь- ко самые необходимые требования (на это бюджета, как правило, хва- тает), а потом либо будет дополнять данное решение новыми возмож- ностями, либо аргументирует прекращение работ и возьмет на себя ответственность за это.
В любом случае при постановке задачи, как и везде, вредны крайно- сти. Многие проекты были загублены чересчур грамотными аналитика- ми, которые месяцами составляли задания, исчисляемые сотнями стра- ниц. Потом сами же с трудом могли понять, что они имели в виду, на- столько запутана и сложна была задача или ее описание. Поверхностность также вредна. Исходя из практического опыта, мож- но сказать, что ориентирами «золотой середины» могут являться пара- метры объема работ по подготовке технического задания, представлен- ные в табл. 15.
Таблица15
Ресурсы и объем работ по подготовке технического задания
|
Размер банка |
Количество выделенных для постановки задачи аналитиков |
Примерное время для завершения этапа с учетом согласований |
Примерный суммарный объем задания в страницах, с учетом комментариев |
|
Небольшой |
2-3 |
1 — 2 месяца |
100-150 |
|
Средний |
4-5 |
3 месяца |
200-300 |
|
Крупный |
6-8 |
4 — 5 месяцев |
350-500 |
