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