Коммуникаций российской федерации федеральное государственное бюджетное образовательное
 Скачать 55.8 Kb.
|
|
Информационная технология и управление предприятием Сегодня положение дел в рассматриваемойобласти характеризуется крайней неопределенностью. Во-первых, это связано с непрерывным увеличением объема технологических предложений, требующих высоких инвестиций, и соответственно с усилением зависимости от внешних услуг (например, от поставщиков программного обеспечения). Внутрифирменные ассигнования на нужды ИТ растут опережающими темпами по сравнению с другими затратами предприятия. При этом высший менеджмент мало осведомлен об общих расходах в сфере ИТ. Так, компетентные решения фирменного руководства охватывают примерно лишь 5% соответствующих затрат. Во-вторых, изменяется роль ИТ в хозяйственной деятельности многих предприятий. При выполнении внутрифирменных процессов функция ИТ перестала быть вспомогательной, превратившись в важнейшую составную часть продукта или производственных мощностей. Хозяйственные риски в настоящее время во многом определяются рисками в данной сфере. Реализация же современных высокопроизводительных организационных проектов (например, "виртуальных организаций" без жесткой привязки производственных участков к определенному месту), требует полного использования потенциала ИТ с помощью телекоммуникационных средств. Не способствует стабилизации быстрый рост издержек в сфере ИТ. Чтобы контролировать их увеличение и добиться большей гибкости в решении информационно-технологических проблем, многие предприятия идут в основном двумя путями. Первый заключается в том, что фирма создает внутрифирменный информационно-технологический участок, который предлагает услуги и внефирменному рынку, доказывая тем самым возможность рентабельного использования своих мощностей. Чаще предприятия выбирают другой путь, когда большая часть собственного информационно-технологического персонала переводится в распоряжение вновь создаваемых дочерних компаний или совместных со специализированными информационно-технологическими партнерами предприятий, также самостоятельно выступающих на рынке. На материнском предприятии остается небольшая группа сотрудников, на которую возлагаются функции информационного менеджмента. Высший менеджмент начинает осознавать, какое важное воздействие оказывают информационно-технологические решения на сам хозяйственный процесс и культуру предприятия. Поэтому он чувствует себя все более ущемленным в том плане, что вынужден делегировать соответствующие вопросы внутрифирменным подразделениям или внешним организациям. К тому же первый опыт работы внефирменных информационно-технологических служб не дает особых поводов для оптимизма относительно эффективности решения указанных проблем. В этой связи возникают следующие ключевые вопросы: каково отношение ведущего персонала к ИТ, какие последствия вытекают из более эффективной ее организации и использования в производстве новых товаров и услуг; что должно знать высшее руководство фирмы в области ИТ, чтобы принимать компетентные решения, в частности в отношении инвестиций; в какой мере допустимо делегирование функций в сфере ИТ; какова должна быть роль высшего менеджмента в управлении информационно-технологическим потенциалом. Поддержка основных функций управления средствами workflow Идеология систем автоматизации деловых процедур основывается на утверждении, что большинство деловых процессов в аппарате управления обладает следующими характеристиками: деловой процесс состоит из конечного набора задач, выполняемых предписанным образом; в деловой процесс вовлечено множество людей с различной степенью ответственности; деловые процессы заключаются в изучении, создании, обработке и передаче информации в различных представлениях, а не только в форме документов; деловой процесс имеет некоторую цель, возможно, не очевидную всем его участникам. Системы автоматизации деловых процессов основываются на комплексном подходе к решению задач управления. Это значит, что они в той или иной мере поддерживают реализацию всех основных функций управления: планирования, организации, активизации, координирования и контроля. Система управления может быть разделена на управляющую и управляемую подсистемы. Управляющая подсистема занимается выработкой управленческих решений. Управляемая подсистема является исполнителем этих решений. Важный показатель эффективности взаимодействия управляющей и управляемой подсистем - обратная связь. Обратная связь - это информация о результатах управленческого воздействия. Управляющая подсистема получает ее от управляемой в виде разнообразных отчетов (документированных и устных). Такая информация помогает оценить полученные результаты и служит основой для выработки новых решений, корректирующих или развивающих предыдущие. Итак, средства автоматизации управленческих процессов (на схеме средства workflow) служат интегрирующим средством при обеспечении взаимодействия управляющей и управляемой подсистемы, которое строится следующим образом. Microsoft Project в управлении проектами Microsoft roject стал фактически стандартом среди средств автоматизации индивидуальной работы менеджеров проектов. Свою популярность он заслужил благодаря удачному сочетанию простоты использования, дружеского интерфейса и наиболее необходимых инструментов управления проектами. Microsoft Project рассчитан, в первую очередь, на пользователей, которые не являются профессионалами в управлении проектами. Таким образом, его можно отнести к «непрофессиональным системам» управления проектами. с другой стороны, с помощью Microsoft Project можно управлять проектами со значительным количеством работ и ресурсов. Microsoft Project входит в семейство Microsoft Office, что подтверждается следующими его свойствами: построение интерфейса и справочной системы на единственных с Microsoft Office принципах; возможность сохранения данных проектов в базе данных Access; двусторонний обмен данными с Outlook; Подавляющее большинство менеджеров, которые пользуются Microsoft Project, использует его для планирования небольших задач. По оценкам, половина пользователей планирует проекты объемом до 50 работ, и только от 10% до 20% – проекты, в которых более 100 работ. Однако, современные версии Microsoft Project вполне пригодные для использования управления и больших проектов. По мнению западных экспертов, Microsoft Project 2002 способный делать расчет расписаний и управления сложными проектами, размер которых достигает как минимум 10000 задач. Он хорошо подходит для управления проектами, которые охватывают несколько отделов, и в которых ключевым требованием является автоматическая разработка графиков работ, прогнозирования хода работ и отслеживания их выполнения. Среди преимуществ Microsoft Project также можно назвать усовершенствованные средства групповой работы, что позволяют одному менеджеру одновременно управлять несколькими проектами с большим числом участников. По мнению Gartner Group, Microsoft Project – лучший выбор для организаций, где используется матричная схема управления, то есть проектные команды допускают взаимодействие сотрудников из разных департаментов. К недостаткам системы можно отнести ограниченные средства управления бюджетом и отсутствие средств для управления рисками проекта. Для расширения функциональности системы разработанные дополнительные модули, доступные для бесплатной загрузки через Internet. Кроме того, существует web-сервис Microsoft ProjectCentral, предназначенный для организации совместной работы над проектами для групп, распределенных территориально. ProjectCentral предоставляет членам рабочей группы и всем заинтересованным лицам веб-страницы для работы с информацией проекта. 3.1. Запуск проекта Перед началом работы над проектом необходимо разбить проект его задачи, описать их связки, оценить трудоемкость задач и описать ресурсы, необходимые для реализации проекта. Это является исходной информацией для работы Microsoft Project, и, как правило, эту работу выполняет менеджер. На основе этой информации система автоматически составляет подробный календарный план хода выполнения работ, определяет критические пути, выполняет расчеты бюджетных расходов, предоставляет членам команды всю необходимую информацию и отображает ее в удобном для анализа виде (Рис.1). Рис. 1. Окно программы Microsoft Project После того как исходный план сложен, но до того, как начать разработку структуры проекта, необходимо создать файл проекта, ввести предыдущие данные, а также прибавить в проект документы, которые относятся к его планированию (табл. 1). Таблица 1. Действия при создании нового проекта
Введение задач. Календарный план проекта в Microsoft Project складывается на основании введенных пользователем данных о проекте в целом, об отдельных его элементах – задачах, при необходимости – о ресурсах (рабочую силу, оборудование и материалы), которые нужны для выполнения этих задач. Если какие-то данные по проекту изменяются после создания календарного плана, можно обновить задачи или ресурсы, после чего Microsoft Project скорректирует календарный план. За умолчанием структура задач проекта Microsoft Project представлена в виде перечня задач и диаграммы Ганта. Более для удобной для пользователя настройки представлений используют «Мастер Диаграмм Ганта» (рис. 2). В Microsoft Project можно вводить задачи двух видов: задачи, которые выполняются одноразово, и задачи, которые повторяются (с заданными параметрами повторения). Для всех задач нужно ввести значение длительности, зависимости задач и ограничения, после чего Microsoft Project рассчитывает дату начала и дату окончания каждой задачи. Также можно ввести в проект ресурсы и назначить их задачам, чтобы указать, какой ресурс является ответственным за завершение каждого назначения, и рассчитать, какое оборудование будет нужно или сколько материала будет потрачено. Если вводятся ресурсы, то календарные планы задач становятся более детальными за счет данных о затратах труда, единицы измерения и рабочее время, которые вводятся в календаре. На планирование могут повлиять и другие элементы, такие как время опережения и время опоздания, типы задач, доступность ресурсов. Создание структуры проекта. Для систематизации календарного плана в Microsoft Project можно использовать структуру, которую можно задавать по ходу введения задач или проекта после того, как все задачи введены. Структуризация позволяет организовать задачи в виде иерархии суммарных задач и подзадач. За умолчанием все суммарные задачи выделяются полужирным шрифтом и располагаются с выступлением, а подзадачи отображаются под ними с отступлением. Суммарные задачи помогают выделить основные и промежуточные этапы проекту. Они подытоживают данные подзадач, сгруппированных в структуре под соответствующей суммарной задачей. В структуре можно установить любое количество уровней, необходимое для воссоздания схемы организации проекта. Для обозначения важного события, например, завершение большого этапа, в календарном плане используют вехи – задачи с нулевой длительностью. Кодировка задач. Структуру проекта в Microsoft Project можно задать и отобразить несколькими способами. Кроме суммарных задач и вех для этого также используют коды структурной декомпозиции работ (СДР) или коды структуры. Структурная декомпозиция работ (СДР) – это иерархия задач в проекте, которая отражается последовательностями цифр, литер и их комбинациями. Microsoft Project позволяет представить структурную декомпозицию работ с помощью идентификаторов задач или с помощью кодов СДР. Код структурной декомпозиции работ (СДР) – это литерно-цифровой код, что однозначно определяет место расположения каждой задачи в общей структуре проекта. Коды СДР можно использовать для описания календарного плана и отслеживания расходов. В Microsoft Project применяются коды СДР двух типов. Первый тип кодов – номер в структуре. Он автоматически вычисляется для каждой задачи на основе структуры перечня задач. Номер в структуре является только числовым; его нельзя изменить, но он автоматически корректируется при перемещении задачи вверх или вниз за перечнем задач или при изменении уровня задачи. Второй тип кодов СДР – код, который настраивается вручную. Для каждого проекта можно определить один набор настраивающих кодов СДР. Каждый уровень кода СДР является представлением определенного уровня структуры перечня задач. Но в отличие от номеров в структуре, уровни кода могут содержать буквы, цифры и знаки (комбинации букв и цифр), в зависимости от того, как были заданы ровные маски кода при создании кода СДР. Можно задать автоматическое вычисление таких кодов для новых задач, а также позволить повторение кодов СДР в разных задачах. Коды структуры – это настроенные отметки задач или ресурсов. Их используют для группировки задач или ресурсов проекта нестандартными способами, например, по кодам расходов (для задач) или по кодам должностей (для ресурсов). Перед тем, как группировать задачи или ресурсы по коду структуры, необходимо создать код структуры и назначить его задачам или ресурсам. Всего можно создать до 10 разных кодов структуры. Установление зависимостей между задачами. Определив, из каких задач состоит проект, необходимо установить последовательность их выполнения, связав между собой задачи, которые зависят одна от другой. Например, некоторые задачи должны быть закончены, чтобы можно было начинать другие (Рис. 3). Рис. .3. Установление связей между задачами проекта Для установления связей между задачами необходимо определить зависимость между датами их начала или окончания. Существуют четыре типа зависимостей: окончание-начало, начало-начало, окончание-окончание, начало-окончание (табл. 2). Таблица 2. Типы зависимостей между задачами
Оценка длительности задачи. При добавлении задач к перечню задач нужно ввести для каждой из них ее длительность и связки. Даты начала и окончания будут вычислены в Microsoft Project автоматически. Для достижения максимальной гибкости при планировании стоит избегать жестких ограничений даты начала или окончания задачи. При введении новой задачи в Microsoft Project, ей автоматически назначается длительность в один день. Вопросительный знак возле длительности указывает, что это лишь предыдущая оценка. Задаче можно назначить астрономическую длительность. В этом случае длительность будет планироваться без учета нерабочего времени и выходных. Для оценки длительности задач может быть использован анализ за методом PERT. После установления оптимистичной, пессимистической и ожидаемой длительности задач календарного плана выполняется расчет взвешенной величины этих трех значений (рис.4). Кроме того, оптимистичные, пессимистические и ожидаемые значения могут использоваться отдельно для определения наиболее ранней, поздней и вероятной дат окончания проекта. Если вместо дат предполагаемого начала и окончания задач вводить их длительность, Microsoft Project автоматически создаст календарный план проекта. Этот план можно будет впоследствии уточнить, перерывая те или другие задачи или создавая отдельные календари задач. За умолчанием в Microsoft Project задаче планируются в соответствии с периодами рабочего времени, установленными в календаре проекта. Однако можно использовать отдельные календари задачи. Они позволяют определить индивидуальные исключения для отдельных задач, например, если оборудование функционирует в нерабочее время или в рабочее время требует проведения работ из обслуживания. Контроль за выполнением задач можно осуществлять с помощью крайних сроков для задач. Крайние сроки не являются ограничениями. При возобновлении календарного плана задача, которая не закончилась к крайнему сроку, отражается индикатором. Перерыв в работе над задачей. Иногда для определения характера зависимости между задачами недостаточно установление связи. Чтобы показать, что время выполнения задач перекрывается, задают время опережения задачи. Если же нужно установить задержку между выполнением задач, устанавливают время опоздания. Время опережения – это время перекрытия задач, которые зависят одна от другой. Например, если можно запустить задачу, когда задача-предшественник закончена только наполовину, для задачи-последователя задают зависимость «окончание-начало» со временем опережения 50%. Время опережения вводится как отрицательное значение времени опоздания. Время опоздания – это задержка между задачами, которые имеют зависимость. Например, если между окончанием одной задачи и началом другой задачи нужная задержка в два дня, между ними устанавливают зависимость «окончание-начало» и задают время опоздания в два дня. В процессе уточнения календарного плана может возникнуть необходимость прервать выполнение задачи. Например, выполнение одной из задач проекта может требовать материалов, которые будут поставлены только через неделю; или может оказаться, что какие-то две задачи по плану выполняются одновременно и используют один ресурс. Если календарный план позволяет, можно прервать одну из задач, чтобы часть работы была выполнена к началу второй задачи, а другая часть – по окончании этой задачи. Задачу можно перерывать несколько раз. |