Контрольная работа по дисциплине: «Информационный менеджмент»

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Федеральное Государственное Учреждение

Высшего Профессионального Образования

«Тихоокеанский  Государственный Университет» 

Кафедра: «Экономическая кибернетика» 
 
 
 
 

Контрольная работа

по дисциплине: «Информационный менеджмент». 
 
 
 
 
 

Выполнил: студентка 2-го курса з/о

                                                                                                Специальность  ПИЭзу

                                                                               № зач.книжки 090440680

                                                                                 Ф.И.О   ФЕДОРОВА С.Е. 
 
 

Хабаровск 2011 
 
 
 
 

Содержание 
 

1.Создание временных  коллективов для внедрения ИТ  и ИС 

и их менеджмент                                                                                                         3 

2.Приемы менеджмента  для каждого этапа на фирмах-производителях  и            фирмах-потребителях                                                                                               10 

3.Список используемой  литературы                                                                       13                                    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Создание  временных коллективов  для внедрения  ИТ и ИС и их менеджмент 

Вся структура  предприятия, задействованная в  процессе управления всеми информационными  потоками, является информационной системой.

Информационная  система (ИС) включает всю инфраструктуру организации, задействованную в процессе управления всеми информационными, документальными потоками. С ростом технической мощи ИТ компьютеры начали не просто облегчать работу менеджера, а позволяют выполнять функции недоступные без использования ИС. Такими функциями являются оперативный финансовый и экономический анализ, оперативный учет рисков, принятие решения в условиях рисков и неопределенности (биржевые операции), проведение платежей в режиме реального времени, динамическое планирование материальных и финансовых ресурсов и многое другое.

В связи с  необходимость решения сложных  комплексных задач менеджмента  получили широкое распространение  ИС «для бизнеса», которые для облегчения работы внедряются на предприятия небольшими группами специалистов.

На группе внедрения  лежит основная нагрузка по выполнению работ,связанных с внедрением ИС на всем предприятии. При формировании группы внедрения необходимо обеспечить вхождение в ее состав представителей всех служб предприятия, затрагиваемых  внедрением.

Чтобы быть эффективной, группа внедрения, как правило, должна быть небольшой по численности. Для  внедрения и эксплуатации интегрированной  ИС класса предприятия, то есть системы  полностью интегрирующей все  управленческие функции среднего или  крупного предприятия, команда внедрения  должна состоять из 4-6 специалистов ИТ-отдела, из них должен быть как минимум 1 - специалист-системотехник (то есть специалист по взаимодействию прикладных задач  и операционно-управляющих систем), 1 - специалист по поддержке БД и программированию. Остальные - специалисты по прикладным подсистемам, а также специалисты  от подразделений, которые затрагивает  проект внедрения (эти подразделения  определяются на этапе определения  связей проекта). Эти специалисты  должны хорошо знать работу предприятия  в своей области, хорошо представлять себе всю бизнес-деятельность предприятия, уметь грамотно сформулировать задачи для проекта внедрения, в идеале - иметь опыт работы с ИС.

В эту группу обычно не включаются специалисты по поддержанию работоспособности  локальной вычислительной сети и  технических средств связи, хотя в ряде случаев возможно частичное  совмещение функций, но как правило  не на этапе внедрения. Также не включается персонал, необходимый для ввода  данных при "неполном охвате" или "неполной интеграции" системы, что  часто встречается из-за экономии финансовых средств. Естественно, в  каждом подразделении, должны быть выделены и подготовлены "квалифицированные  пользователи" обеспечивающие поддержку  эксплуатации функциональных блоков продукта. Как правило, в традиционную проектную  группу не входят такие важные для  проекта роли, как конечные пользователи и структуры, выполняющие контроль качества и обучение пользователей. Это повышает риски, удлиняет сроки  проектирования, снижает качество продукта.

Если группа внедрения много меньше, то будет  достаточно сложно внедрить систему  на всем предприятии сразу. Кроме  того, это может сказаться на качестве принятых решений. Если же группа слишком  большая, то вклад членов группы, способность  принятия решения и эффективность  выполнения задач внедрения могут  значительно упасть.

Если предприятие  располагает внушительным бюджетом, позволяющим привлечь большую группу экспертов для разработки ИС, то со стороны заказчика в группу могут входить, помимо выделенных для  данного проекта ИТ-специалистов, менеджеры отделов и ключевые пользователи. Следует позаботиться о том, чтобы все участники  группы к моменту начала работ  прошли соответствующее обучение методологии  моделирования ИС, основам проектирования больших систем, а также приобрели  минимальные навыки работы с будущей  ИС — познакомились с архитектурой системы, основами навигации по системе, функциональным назначением подсистем  и т.п.

Нецелесообразно включать в группу внедрения свыше  десяти человек, так как в этом случае группа становится трудноуправляемой . При необходимости увеличения количества человеческих ресурсов, задействованных  во внедрении, предпочтительнее создавать  несколько отдельных групп –  по одной на каждое предприятие или  крупное структурное подразделение. Но руководство ими осуществлять из одного центра (одним человеком).

Правило выбора членов группы внедрения заключается  в следующем: « Из каждого подразделения по одному представителю, которого организация может позволить выделить под проект, и которого вы хотите видеть в группе внедрения » . Члены группы внедрения должны видеть всю ситуацию целиком, для того чтобы перевести процессы предприятия на качественно более высокий уровень. Они должны уметь мыслить шире, нежели в рамках их профессиональной деятельности. Каждый член группы внедрения должен взять на себя полную ответственность за понимание своей функциональной области и областей, с которыми им приходится сталкиваться в процессе непосредственной работы на предприятии.

Члены группы внедрения  должны нести ответственность за качество и сроки выполнения возложенных  на них задач. Поэтому при планировании проекта необходимо оценить, сколько  времени и ресурсов понадобится  членам группы внедрения для того, чтобы выполнять работу в рамках проекта, а также определить сферы  их ответственности. Это может потребовать  передачи им дополнительных полномочий, выделения ресурсов, временного изменения  их рабочих позиций.

Основное требование к членам группы внедрения: те, кто будет систему использовать, должны ее и внедрять . Члены группы внедрения должны:

• решать, что наиболее приемлемо для данного предприятия, и предлагать соответствующие корректировки бизнес-процессов предприятия;
• понимать слабые и сильные стороны их подразделений с точки зрения персонала и процессов при разработке процедур в своей функциональной области;
• иметь полномочия для изменения текущих процедур, установки или изменения сферы ответственности подразделений, а также для создания или ликвидации структурных единиц или должностей в организации, связанных с рекомендуемыми операционными изменениями.

Общие обязанности членов группы внедрения:

• брать полную ответственность за свою функциональную область;
• посещать все собрания, связанные с внедрением, и принимать в них активное участие;
• понимать цели и способы их достижения в рамках своей функциональной области;
• разрабатывать детальные процедуры на основе знаний, полученных в процессе обучения и на этапе тестирования;
• определять программные продукты, которые не поставляются вместе с системой, но применение которых необходимо в их функциональной области, а также все возможные изменения, которые могут понадобиться вносить в способы управления предприятием или в систему (что нежелательно);
• участвовать в переносе данных в систему, а также быть ответственным за их достоверность в рамках своей функциональной области;
• после окончания внедрения составить обзорный документ по своим функциям с целью выявления открытых вопросов.

Но и в случае эффективной проектной группы есть несколько тонких мест, на которые  следует обращать внимание:

• большая численность проектной группы может требовать очень много времени для общения, чтобы реализовать концепцию "каждый общается с каждым";
• высшее руководство имеет ограниченный контроль за внутренними взаимоотношениями и процессами в проектной группе;
• члены проектной группы должны полностью понимать и принимать свои роли. Основной целью работы эффективной проектной группы является создание качественного продукта. Для достижения этой цели наиболее подходят самоуправляемые малые группы, или "команды". Под качественным продуктом подразумевается такой продукт, который:
• удовлетворяет ожиданиям заказчика и конечных пользователей; удовлетворяет проектным ограничениям;
• соответствует реальным потребностям заказчика;
• понятен в использовании заказчику и конечным пользователям;
• гладко внедряется (что обеспечивается на этапе проектирования).

Имеется положительный  опыт разработки и ведения проектов, когда новая организация отношений  между подразделениями ускоряет иногда в несколько раз процесс  создания отдельных деталей и  узлов. Но применять широко этот опыт в условиях сложившихся “де-факто” отношений между подразделениями  повсеместно и для всего изделия  крайне затруднительно. Проблем возникает  столько много, что даже энтузиасты не готовы идти на ломку сложившихся  стереотипов. Нужно время для  накопления опыта, нужны новые подходы  к решению проблем. Одним из начальных  моментов можно считать целесообразность создания временных рабочих групп  для работы над единым проектом для  выработки методики работы и основных, возможно, новых подходов в конструировании, которые должны стать стандартными для последующих проектов (например “конструктор детали - конструктор  оснастки”). Важнейшим следствием поддержки  внедрения со стороны руководства  компании служит состав группы внедрения  – команды проекта. Проект идет существенно  более эффективно, если в нее включены, на временной основе, сотрудники большинства  структурно-функциональных подразделений. Существует правда и успешная практика реализации проектов и силами только сотрудников подразделений ИТ, но в среднем такие проекты идут тяжелее и требуют более длительного  периода обучения и "вхождения" в проблематику.

Командный менеджмент - менеджмент, который осуществляется посредством создания и функционирования управленческих команд, как одна из форм коллективного управления, основан  на процессе делегирования полномочий. Почти все организации наделяют менеджеров различных уровней ответственностью за более широкий круг задач, нежели тот, с которым они могли бы справиться лично. Кроме того, в определенном смысле тяжелым психологическим  фактором для топ-менеджеров, является то, что они, в связи с отсутствием  специальных знаний/времени, просто вынуждены делегировать полномочия для решения вопросов по внедрению  ИТ и созданию ИС внутренним подразделениям или внешним организациям.

На основании  ранее сказанного следует сделать  вывод, что топ-менеджеры современного предприятия, вынуждены принимать  решения о разработке, развитии и/или  дальнейшего совершенствования  производственных ИС, а поэтому неизбежно  сталкиваются со следующими проблемами]:

• необходимостью включения вопроса об информатизации, компьютеризации и автоматизации производственных процессов в перечень важных и первостепенных. Если раньше решением вопросов, связанных с информатизацией, можно было пренебречь, то состояние современного рынка изделий машиностроения делает такое пренебрежение невозможным: уровень управляемости предприятия; рентабельность производства; выгодные контракты, кредиты, инвестиции; отечественный и международный имидж - все это сегодня самым непосредственным образом зависит от уровня использования ИТ.
• для успешного решения вопросов по внедрению ИТ и ИС создаются те или иные формы коллективного управления, основанные на перераспределении ответственности. В успешных управленческих группах выработка и принятие решений осуществляется непосредственно группой, а роль администратора сводится к тому, чтобы создать для этого необходимые условия, определить границы пространства решения и дать в затруднительном случае необходимый совет.
• сами являются профессионалами в области машиностроения, управления, финансового менеджмента производством, но вряд ли обладают достаточно глубокими знаниями в области ИТ. Это связано с тем, что их карьерный рост обеспечивался именно ростом профессиональных знаний в конкретной предметной области. Процесс эффективного внедрения ИТ является настолько специфичной областью, что для принятия решений здесь порой недостаточно оказывается накопленного управленческого опыта и традиционного подхода "от здравого смысла" - необходимы специальные знания, навыки глобально-системного мышления, которые не так-то просто восполнить, учитывая чрезмерную загрузку наших руководителей текущей, оперативной работой;
• определение места подразделения и его первого руководителя, отвечающего за разработку и внедрение ИТ, в организационно-управленческой структуре предприятия. Кроме того, достаточно сложно принять мнение, что не все задачи информатизации могут решаться собственными силами;
• привлечение специалистов в области социальной психологии для определения сторонников и противников внедрения ИС.

В связи с  тем, что в области реализации изменений (реинжиниринга) в работе предприятия заключается основная проблема проекта внедрения, то главный  вопрос, на которые необходимо ответить высшему руководству предприятия  при принятии решения о том, какими силами реализовывать проект - может  ли предприятие подобрать таких  специалистов, которые могли бы обеспечить максимально эффективное использование  возможностей ИТ и ИС для удовлетворения потребностей предприятия, а также  смогли бы организационно обеспечить проект внедрения, т.е. быть "мотором" проекта. Кроме того, внедряющая фирма  со своей стороны может потребовать  назначения ответственными за внедрение  действительно значимых в организации  лиц, с четко оговоренным временем, которое они будут тратить  на руководство проектом. Руководители некоторых предприятий стараются  избегать внедрения ИС, опасаясь, что  ее не будут использовать, а если будут, то неэффективно. К тому же сотрудники, которые приобретут новые навыки в процессе внедрения системы, могут  покинуть компанию, и тогда будет  трудно найти технические ресурсы  для поддержания ее функционирования.

Эти опасения вполне оправданны. Проекты по внедрению  систем и в самом деле терпят неудачу, даже в компаниях с эффективным  в остальных отношениях управлением. В тех же случаях, когда все  идет более или менее нормально, зачастую не выполняются сроки начала промышленной эксплуатации и не удается  остаться в рамках выделенного бюджета. При надлежащем планировании и управлении вполне можно соблюсти намеченные сроки  и остаться в рамках бюджета. Разработка и реализация плана управления внедрением ИС имеют важнейшее значение. Как  правило, процесс управления внедрением ИТ и ИС можно разбить на пять этапов.

• создание команды внедрения;
• оценка сложившейся ситуации с распределением и использованием ИТ и ИС;
• разработка плана управления внедрением;
• реализация плана и проведение корректировки;
• продолжение выполнения плана по внедрению.

Большое влияние  на командные процессы оказывают  также особенности личного стиля  взаимодействия ее руководителя или  лидера с другими членами команды. Даже работая с группой высококвалифицированных  и энергичных специалистов, руководство  столкнется с массой проблем. Часть  из специалистов обладает огромным самомнением, большинству очень давно не приходилось  работать на подхвате. При отсутствии серьезного менеджмента им будет  крайне сложно добиться успеха.  

Приемы  менеджмента для  каждого этапа  на фирмах-производителях и на фирмах-потребителях. 

Инновационные мероприятия в сфере информатизации призваны обеспечить своевременное  и эффективное внедрение новых  и новейших достижений для успешного  и эффективного ее развития. 

Корпоративные заказчики выплачивают миллионы долларов ведущим производителям и  консультантам, в конечном счете  вверяя им свое будущее. Но руководителям  информационных служб при этом хотелось бы убедиться в том, что нынешние лидеры в области высоких технологий завтра не утратят позиций и фирма  не попадет в плен устаревшей технологии. 

Лидеры рынка, закрепившиеся на своих позициях, иногда склонны сознательно избегать кардинальных изменений технологии до самого последнего момента; примерами  могут служить равнодушное отношение  IBM к зарождению ПК, отрицательное отношение Кеннета Олсена (DEC) к RISC-процессорам, а также то, как Microsoft пропустила возникновение Интернет. 

Обычно фирмы  уделяют основное внимание закупочным ценам, однако не менее важно проанализировать планы производителей в отношении  модернизации их продукции с учетом появления новых технологий. И  быстрый рост оборота, и значительные расходы на исследования и разработки далеко не всегда преобразуются в  новые технологии. К тому же если производитель выпускает продукты, которые необходимы потребителям именно сейчас, то это хорошо только на первый взгляд: слишком сильная ориентация на пользователей приводит к недооценке так называемых «разрушительных» технологий, т.е. тех, которые пока еще не интересуют потребителей. 

В результате может  сложиться ситуация, когда корпоративным  заказчикам понадобится некая радикально новая («разрушительная») технология, а производитель, следовавший на поводу у пользователей по пути развития стабильных технологий, вполне вероятно, упустит подходящий момент ее внедрения. В свою очередь, и потребитель  почти так же беспомощен перед  «разрушительной» технологией, как  и производитель. 

Существует несколько  достаточно расплывчатых методик, которые  могут выявить инновационную  готовность производителей.

Одна из них  – ориентация на разработку прототипов. Она возникла на основе изучения методов, используемых компаниями, выпускающими аппаратное и программное обеспечение. Дело в том, что традиционная модель разработки ориентируется на спецификации, т.е. компания анализирует требования к системе, пишет и утверждает спецификацию, а затем постепенно реализует продукт. Эту модель еще называют каскадной или подходом «сверху вниз».

Подход, ориентированный  на создание прототипов, намного более  адаптивен: разработчик быстро создает  прототип и затем совершенствует его. В средах, которые быстро меняются, модель разработки на основе прототипов выглядит более подходящей. Все, кто  работает в мире Интернет, отдают предпочтение именно этой модели. К примеру, Microsoft использует прототипный подход к исследованиям и разработке офисных приложений. 

Правда, несмотря на преимущества прототипной разработки, руководители корпоративных информационных служб считают более удобной  модель, определяемую спецификациями, как более предсказуемую. В то же время многие потребители скорее предпочтут увидеть работающий прототип, на создание которого ушло меньше месяца, а затем еще шесть месяцев  понаблюдать за его развитием, а  также за реакцией разработчика на свои замечания, чем после пятимесячного  ожидания результата воплощения спецификаций получить продукт, который совсем не похож на то, что нужно.

Интерес представляет и то, сколько проектов производитель  разрабатывает одновременно. Выявлено, что средняя высокотехнологичная  компания обычно пытается разработать  больше продуктов, чем в состоянии  сделать. Общее же эмпирическое правило  состоит в том, что ведущие  специалисты должны вести не более  двух ключевых проектов одновременно. 

Администраторы  ИС также должны внимательно изучить  стратегию приобретений, принятую их поставщиками. Например, некоторые  доминирующие корпорации типа Cisco и Microsoft пришли к выводу, что целесообразнее приобретать идеи для продуктов следующего поколения у начинающих фирм, чем генерировать их самим. Анализируя приобретения компании и судьбу купленных ими технологий, администраторы ИС могут получить представление о способности поставщика воспользоваться новым «имуществом». Покупка, а не создание новой технологии – это законный и даже эффективный подход, хотя, вероятно, он все же свидетельствует о том, что такая компания скорее склонна сразу извлекать из будущего коммерческую пользу, вместо того чтобы это будущее создавать собственными силами. Конечно, подобный подход может оказаться успешным, если компании-покупатели сохранят свой основной персонал и будут финансировать продолжительные разработки. 

Как показывает зарубежный опыт, представляет интерес  также и оценка практики сотрудничества фирм с университетами и лабораториями.

Не все фирмы  в состоянии сами решать задачи оценки возможностей поставщика и его технологии. За рубежом обычно всегда находятся  независимые компании, готовые решать эти задачи за определенную плату. Более  того, независимые консультанты и  системные интеграторы помогают выявить и испытать еще не вышедшие из стен исследовательских лабораторий  перспективные технологии. Такие  независимые испытания нужны  еще и потому, что большинство  крупных компаний обычно стараются  скорее продвинуть пусть и перспективные, но еще сырые технологии на рынок.

Руководители  информационных служб предприятий  при выборе поставщиков склонны  недооценивать необходимость анализа  их стратегии в области инноваций. Однако проблема инноваций именно в  сфере информатизации всегда возникает  при выполнении программ развития в  самых разных областях деятельности. Более того, при развитии любой  сферы деятельности практически  неизбежно нужно проводить инновационные  мероприятия по информатизации. 

В качестве примера  можно привести характерную ситуацию, сложившуюся летом 1998 г. в европейских  финансовых учреждениях вокруг перехода европейских стран на единую европейскую  валюту евро. Страны, отказывавшиеся от перехода на евро, в качестве одного из основных аргументов приводили необходимость существенных изменений в банковской сфере, прежде всего в области ее информатизации. Банки этих стран стояли перед необходимостью создания или приобретения программных средств, работающих в двух или более валютах. Ранее у них такие операции не требовалось обеспечивать, и таких программ во многих банках просто не было. Оказалось, что для этого требуются огромные средства. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Список  используемой литературы: 

1. Каляное Г.Н. Консалтинг при автоматизации предприятий, 
   Подходы, методы, средства.
2. Карминский А М., Нестеров П. В. Информатизация бизнеса. - 
   М.: Финансы и статистика.
3. Инновационный менеджмент: Учебник для вузов / С.Д. Ильенкова, А.Н. Гохберг, С.Ю., Ягудин  и др.; Под. ред. С.Д. Ильковой.