ТОР 5 статей: Методические подходы к анализу финансового состояния предприятия Проблема периодизации русской литературы ХХ века. Краткая характеристика второй половины ХХ века Характеристика шлифовальных кругов и ее маркировка Служебные части речи. Предлог. Союз. Частицы КАТЕГОРИИ:
|
Системы среднего уровняПоявление на российском рынке систем среднего уровня было обусловлено потребностями клиентов получить в свое распоряжение инструмент, который давал бы возможность работать с более широким спектром задач. Некоторые из компаний постарались расширить функциональные возможности своих продуктов. Кроме того, современные способы и средства разработки позволяли создавать готовые решения, охватывающие широкий круг потребностей предприятий, за довольно короткое время. Как правило, в их состав могут входить следующие подсистемы: Бухгалтерский учет, Управление производством, Материально-техническое снабжение и сбыт, Планирование, Производство. Причем планирование и производство реализовано в очень усеченном виде. Однако несомненным достоинством систем этого класса является возможность вести учет практически по всем направлениям деятельности предприятия. Подобные системы предназначены для работы в сети предприятия со значительным количеством пользователей. Как правило, они имеют файл-серверную или клиент-серверную архитектуру. Стоимость автоматизированной системы управления предприятием данного класса может колебаться от нескольких сотен долларов до нескольких десятков тысяч долларов в зависимости от масштабов организации, а также от фирмы-изготовителя и платформы, на которой реализована система. Ввиду того что система среднего класса позволяет вести учет практически по всем направлениям деятельности предприятия, количество параметров настройки у нее достигает значительного числа. При покупке такой системы следует обращать внимание на стоимость не только лицензий на программный продукт, но и услуг по внедрению системы. В типовой состав таких услуг, как правило, могут входить следующие: • анализ деятельности предприятия (или предпроектное обследование), который включает в себя сбор данных о типовых бизнес-процессах предприятия, его документообороте Системы среднего уровня Появление на российском рынке систем среднего уровня было обусловлено потребностями клиентов получить в свое распоряжение инструмент, который давал бы возможность работать с более широким спектром задач. Некоторые из компаний постарались расширить функциональные возможности своих продуктов. Кроме того, современные способы и средства разработки позволяли создавать готовые решения, охватывающие широкий круг потребностей предприятий, за довольно короткое время. Как правило, в их состав могут входить следующие подсистемы: Бухгалтерский учет, Управление производством, Материально-техническое снабжение и сбыт, Планирование, Производство. Причем планирование и производство реализовано в очень усеченном виде. Однако несомненным достоинством систем этого класса является возможность вести учет практически по всем направлениям деятельности предприятия. Подобные системы предназначены для работы в сети предприятия со значительным количеством пользователей. Как правило, они имеют файл-серверную или клиент-серверную архитектуру. Стоимость автоматизированной системы управления предприятием данного класса может колебаться от нескольких сотен долларов до нескольких десятков тысяч долларов в зависимости от масштабов организации, а также от фирмы-изготовителя и платформы, на которой реализована система. Ввиду того что система среднего класса позволяет вести учет практически по всем направлениям деятельности предприятия, количество параметров настройки у нее достигает значительного числа. При покупке такой системы следует обращать внимание на стоимость не только лицензий на программный продукт, но и услуг по внедрению системы. В типовой состав таких услуг, как правило, могут входить следующие: • анализ деятельности предприятия (или предпроектное обследование), который включает в себя сбор данных о типовых бизнес-процессах предприятия, его документообороте и т. п. с представлением информации в виде, понятном как для покупателя (проверка соответствия описания реальному положению дел), так и для специалистов фирмы-разработчика, которые в дальнейшем будут устанавливать и настраивать систему; • инсталляция и настройка системы в соответствии с результатами предыдущего этапа; • обучение пользователей работе с системой; • сервисное обслуживание на требуемый срок («горячая линия», выезд консультантов, обновление версий и т. п.). Успех внедрения систем среднего уровня во многом зависит от качества выполнения анализа деятельности предприятия. Этого не должны недооценивать руководители предприятий любого уровня, которые приняли решение использовать в своей организации подобную систему. Как показано выше, многие российские компании стали включать в состав своей продукции и возможности планирования. Однако лишь зарубежные системы класса MPRII или ERP позволяют вести полнофункциональное планирование для всех ключевых бизнес-процессов современного предприятия (в первую очередь для производства). Таким образом, на отечественном рынке появляются системы высшего класса.
Системы высшего уровня Как было отмечено ранее, современные версии систем'высшего уровня обеспечивают планирование и управление всеми ресурсами организации. В системах этого класса содержится описание тысяч бизнес-процессов. И действительно, они должны обладать большой избыточностью для того, чтобы успешно использоваться на самых разных предприятиях. Количество настраиваемых параметров в такой системе может достигать десятков и даже сотен тысяч. Безусловно, возрастает и суммарная стоимость решений, причем на первое место выходят затраты, связанные с внедрением. Хотя многие компании, предлагающие ERP-системы, и утверждают, что стоимость их внедрения в России равна или даже меньше стоимости лицензий на систему, реально дело обстоит несколько сложнее. Во-первых, для западных компаний принята система оплаты работ не с фиксированной ценой, а с повременной оплатой. Поэтому даже если какая-либо из российских фирм-интеграторов, занимающихся внедрением ERP-систем, и указывает конечную стоимость внедрения, то всегда следует иметь в виду, что может потребоваться дополнительное привлечение внешних консультантов. Во-вторых, внедрение сложной системы зачастую требует проведения некоторой реорганизации деятельности, а это уже если не прямые, то значительные косвенные затраты. В-третьих, для успешной эксплуатации системы на предприятии необходимо наличие подразделения, которое бы занималось перенастройкой системы в соответствии с требованиями бизнеса. Сюда относится изменение существующих моделей бизнес-процессов, а также создание новых моделей и предварительное обучение пользователей работе по-новому. Однако перспектива значительных затрат не должна пугать. Ведь с внедрением ERP-системы руководители организации и ее персонал получают инструмент, позволяющий реально планировать и управлять производством. А в условиях современной рыночной экономики это может дать неоспоримое конкурентное преимущество. Кроме того, многие ERP-системы позволяют стыковаться с CAD/CAM-системами (системами автоматизированного проектирования — САПР и автоматизированными системами управления технологическим процессом — АСУТП), что позволяет получить интегрированное решение, объединяющее процессы разработки, производства и поставок. осуществить выбор технической системы, руководствуясь только критериями, приведенными в табл. 10, невозможно. Поэтому при выборе системы потребности бизнеса, сформулированные в терминах бизнеса, должны быть конвертированы в технические и экономические требования к системе, сформулированные в соответствующих терминах: • функциональные возможности, • совокупная стоимость владения, • перспективы развития, поддержки и интеграции, • технические характеристики. Ниже эти критерии рассматриваются подробнее.
Функциональные возможности • Стратегия развития бизнеса и контекстное описание бизнеса. • Формализованное описание деятельности предприятия. Лучше всего, если это будут модели деятельности предприятия, выполненные согласно методикам структурного анализа: диаграммы согласно стандартам IDEF0 или IDEF3; диаграммы потоков данных или модели бизнес-процессов. В идеальном случае стратегия развития бизнеса и контекстное описание бизнеса должны содержаться в стратегическом плане автоматизации предприятия. Если исходные данные для выбора системы отсутствуют, то в план выбора системы необходимо включить этап по подготовке исходных данных для выбора системы, иными словами, разработать Техническое задание на систему. Как видно из общего перечня работ, для их успешного осуществления необходимо наличие и постоянное участие квалифицированных специалистов из самых различных областей: информационные технологии, управление персоналом, управление предприятием, планирование и многие другие. Держать такой штат в организации, как правило, экономически нецелесообразно. Поэтому наиболее предпочтительно привлечение внешних консультантов. В пользу этого можно привести следующие основные аргументы: • внешний консультант обладает особыми навыками и знаниями, которых может не быть у сотрудников организации; • даже если в организации и есть требуемые квалифицированные кадры, то они могут быть заняты решением других проблем; • внешний консультант может показать реальное положение дел, так как он независим от организации-заказчика; • при оказании консультационных услуг персонал заказчика перенимает определенные технические знания, проходит обучение. Так что же реально можно получить на этапе определения потребностей предприятия в информационной системе? Не касаясь стратегических планов организации, о которых довольно много и подробно говорится в современных изданиях по теории менеджмента (например, см. [122]), можно отметить, что внешние консультанты могут оказать квалифицированные услуги и по формированию стратегии предприятия. Однако делать это лучше всего после анализа текущей деятельности. Описание существующих бизнес-процессов и информационных потоков предприятия, его организационной структуры и принятых технологий работ позволяет достичь сразу нескольких целей. Во-первых, это помогает персоналу самого предприятия, особенно его руководящему составу, лучше разобраться в работе своей организации. Во-вторых, полученные данные могут сравниваться с передовым опытом различных организаций, с которыми уже работала консультационная фирма. Это позволяет более качественно подготовить предложения по изменению и оптимизации деятельности. В-третьих, даже если предприятию по объективным или субъективным причинам и не требуется реорганизация, структурированные материалы, касающиеся деятельности организации, особенно если они представлены в графическом виде, могут существенно облегчить последующее внедрение системы автоматизации управления предприятием. Кроме того, это позволяет определить, можно ли осуществить изменения в организации после внедрения данной системы и насколько легко это может быть сделано. Реализация этих предложений может происходить до или одновременно с внедрением системы автоматизации управления предприятием. Наиболее просто проблема определения достаточности функциональной полноты решается для систем начального и среднего уровня. Для систем высшего уровня определяются: • Какие типы производства может поддерживать система (разработка на заказ — представляет собой дальнейшее развитие проектно-ориентированного производства; сборка на заказ — предложение клиентам продукции массового производства; работа на склад — поддержание требуемого уровня товарно-материальных запасов в сочетании с организацией поставок со склада; повторяющееся производство — производство, организованное в соответствии с идеологией «точно-в-срок»; процессное производство). • Поддерживает ли система управление цепью поставок. То есть рассматривается возможность ERP-системы управлять поставками, материально-техническим снабжением (логистикой) и спросом. • Как система поддерживает производственные поставки, а также электронные средства поставки. • Насколько полно система управляет процессом материально-технического снабжения, а также складированием продукции и планированием ее доставки. • Как система учитывает работу с клиентами. Требуется оценить, как в системе поддерживается планирование спроса, автоматизация работы с посредниками и торговыми агентами, насколько гибко осуществляется обработка заказов клиентов, а также осуществляется учет сервисного обслуживания.
Совокупная стоимость владения Совокупная стоимость владения (ТСО — Total Cost of Ownership) информационной системой — сравнительно новое понятие, которому в последнее время уделяется самое пристальное внимание в литературе [121, 123]. Под совокупной стоимостью владения понимается сумма прямых и косвенных затрат, которые несет владелец системы за период жизненного цикла последней. При анализе ТСО рассматривают жизненный цикл, включающий в себя время жизни существующей на предприятии системы, время, необходимое для проектирования нового альтернативного решения, срок эксплуатации альтернативной системы с учетом амортизации ее элементов и ориентировочного срока ожидания. Под сроком ожидания понимают время, необходимое для выхода системы на уровень доходности, при котором ее эксплуатация позволяет получить частичный (до 90%) возврат инвестиций, вложенных в систему. При выборе новой информационной системы между альтернативными существующему решению вариантами необходимо оценить совокупную стоимость владения для каждого предлагаемого варианта. При этом жизненный цикл, на котором оцениваются прямые и косвенные затраты, должен включать: • время жизни существующей на предприятии системы; • время проектирования новой системы; • время на закупку и внедрение элементов новой системы; • время эксплуатации новой системы, которое необходимо ограничить сроком возврата 90% вложенных инвестиций за счет прибыли от эксплуатации этой системы. Вариант информационной системы с более коротким жизненным циклом предпочтителен для дальнейшего использования. На рис. 35 самым рациональным является вариант А. Точка выбора новой системы для каждого предприятия индивидуальна. Предприятие может начать этот процесс в различных случаях, например: • при появлении необходимости дополнить или изменить функции существующей информационной системы, чтобы они соответствовали изменившимся потребностям бизнеса и не приводили к неоправданным финансовым потерям;
Рис. 35 1 — точка завершения проектирования существующей системы; 2 — точка завершения внедрения существующей системы; 3 — точка ввода в эксплуатацию новой системы; X — точка выбора новой системы; А — точка возврата 90% инвестиций в новую информационную систему (вариант А); В — точка возврата 90% инвестиций в новую информационную систему (вариант В); С — точка возврата 90% инвестиций в новую информационную систему (вариант С)
• при достижении доходов от эксплуатации существующей системы порядка 90% вложенных в нее инвестиций; • при превышении эксплуатационных затрат на систему над доходами от ее использования и др. Прямые и косвенные затраты могут включать следующие составляющие. Прямые затраты. 1.1. Основные затраты: • создание информационной системы; • оборудование — серверы, клиентские места, периферия, сетевые компоненты; • программное обеспечение (ПО); • приложения, утилиты, управляющее ПО; • обновление (модернизация). 1.2. Эксплуатационные затраты: • управление задачами (сетью, системой, массивами памяти); • поддержка работоспособности системы — персонал, функционирование справочной службы, обучение, закупки, подготовка контрактов на поддержку системы; • разработка инфраструктуры, бизнес приложений. 1.3. Прочие затраты: • создание коммуникаций — глобальные сети, взаимодействие с поставщиками сервиса, удаленный доступ, Internet, доступ клиента; • управление и поддержка — аутсорсинг, сопровождение, справочная система. Все затраты на создание информационной системы, которые ассоциируются с установкой оборудования и его подготовкой к эксплуатации, должны оцениваться как часть инвестиций. Эти разовые затраты могут включать в себя такие составляющие, как проектирование системы, программирование, тестирование системы, ревизия системы, приобретение оборудования, разработка и изменение руководств, обучение и передвижения в связи с установкой, тестированием и параллельным запуском системы. Затраты на оборудование включают в себя стоимость компонент системы, затраты в течение жизненного цикла, такие, как смена оборудования, которое заменяется до истечения жизненного цикла. Затраты на оборудование могут изменения в электропитании, освещении и кондиционировании воздуха. Если часть оборудования берется в лизинг, то суммарные затраты на это оборудование выделяются в отдельную категорию. В табл. 11 перечислены основные виды затрат и их составляющие, которые необходимо учитывать при определении совокупной стоимости владения. Перспективы развития, поддержки и интеграции Перспективы развития и поддержки в основном определяются поставщиком решения и тем комплексом стандартов, который заложен в систему и составляющие ее компоненты. Устойчивость поставщика решения и поставщиков отдельных компонентов определяется в первую очередь временем существования их на рынке и долей рынка (как мирового, так и российского), которую они занимают. Важным фактором является форма, в которой осуществляется присутствие на российском рынке: наличие сети сертифицированных центров технической поддержки, авторизованных учебных центров, «горячих линий» для консультаций. Немаловажным фактором риска могут стать такие показатели, как гарантированное время доставки запасных частей, которое формулируется в терминах: время доставки не превосходит такого-то. В противном случае затраты на владение решением могут стать весьма значительными. Технические характеристики К техническим характеристикам системы относятся следующие: • архитектура системы; • масштабируемость; • надежность, особенно в части выполнения критических бизнес-приложений; • способность к восстановлению при сбоях оборудования; • наличие средств архивирования и резервного копирования данных; • средства защиты от преднамеренных и непреднамеренных технических нападений; • поддерживаемые интерфейсы для интеграции с внешними системами. Технические характеристики влияют на такие параметры системы, как возможность наращивания при необходимости функциональных возможностей и увеличение числа пользователей. Возможность интеграции с другими системами определяется совокупностью поддерживаемых стандартов. Риски и управление рисками Анализ факторов риска Под риском обычно понимается вероятность того, что какие-то цели при реализации проекта автоматизации деятельности предприятия не будут достигнуты. Поскольку количество событий и условий, влияющих на результат проекта, чрезвычайно велико, вся их совокупность, как правило, на практике не рассматривается. Вместо этого из всего множества обычно выделяется достаточно ограниченный перечень характеристик принятого решения. Эти признаки могут касаться как чисто технических решений, так и организации работ, связанных с реализацией решения. В дальнейшем они будут называться факторами риска. Анализ факторов риска предваряют: планирование мероприятий для снижения влияния факторов риска на исход проекта и принятие решений на различных этапах процесса создания автоматизированной системы. Все субъекты, принимающие участие в процессе автоматизации предприятия (предприятие — заказчик и системный интегратор — поставщик), решения производят анализ рисков каждый со своих позиций. В работах, посвященных автоматизации деятельности предприятия, используются различные структуры факторов риска, которые необходимо учитывать при анализе и принятии решений. В настоящей книге рассматривается структура факторов риска, которая в общем виде позволяет представить наиболее существенные составляющие. Элементы этой структуры присутствуют практически во всех самых распространенных подходах к созданию информационных систем для автоматизации деятельности предприятий, независимо от класса системы и применяемого подхода к автоматизации. Все риски делятся на две группы: !) бизнес-риски, 2) риски, связанные с жизненным циклом системы. Бизнес-риски, как правило, анализируются на этапе формирования стратегии автоматизации: при выборе подхода к автоматизации и выборе типа системы. Риски, связанные с реализацией жизненного цикла, как правило, рассматриваются на этапе разработки проекта автоматизации деятельности предприятия. Кроме того, они могут рассматриваться на различных этапах реализации проекта. При анализе бизнес-рисков определяют: будут ли устранены проблемы бизнеса, которые планируется решить с помощью информационной системы, и каким должен быть подход к автоматизации, чтобы был достигнут желаемый эффект. Типичный перечень факторов риска, рассматриваемый на этом этапе, включает в себя следующие позиции: • необходимость и достаточность реализованных функций системы при ведении бизнеса предприятия, • влияние системы на бизнес, • инвестиционный риск, • способность предприятия выполнять график инвестиций, направляемых на реализацию проекта автоматизации. Вторая группа рисков может быть разделена на две подгруппы: 1)технические риски, связанные с реализацией технических решений или работ, связанных с технологией внедрения. Например, инсталляция ПО на какую-либо платформу; 2)риски, связанные с управлением процессом создания и поддержки системы. Например, достижение требуемого качества в заданные сроки при заданных бюджетных ограничениях. Подгруппа технических рисков включает следующие факторы: • количество внешних систем, с которыми новая система должна взаимодействовать, • наличие нестандартного оборудования, • степень новизны оборудования для предприятия-заказчика, • степень новизны оборудования для вендора, • характер приложений: сетевые, локальные и т. д., • уровень знаний участников проекта, исполнителей и пользователей применительно к оборудованию и программному обеспечению, • качество технической поддержки поставщиков компонентов решения, • уровень знаний пользователей в области информационных технологий, которые планируется применить, а также уровень их знаний прикладной области, • степень новизны технических решений для системного интегратора и поставщиков отдельных компонентов, • зависимость изменений структуры бизнес-процессов, организационной структуры предприятия-заказчика и условий работы пользователей от глубины внедрения системы. Подгруппа рисков, связанных с управлением процесса создания системы, включает следующие факторы: • размер системы, количество и география размещения пользователей, • величина трудозатрат и календарных сроков создания системы, • количество слабо связанных между собой проектов, которые необходимо выполнить при создании системы, • количество вендоров, привлеченных к поставкам оборудования и ПО, • количество других проектов, реализация которых определяет успех проекта автоматизации, например, будет полностью или частично зависим, • отношение пользователей и, в частности, высшего управленческого персонала предприятия к проекту создания системы, • наличие совместной команды из пользователей и исполнителей. Как правило, все наиболее известные поставщики решений в области автоматизации деятельности предприятий, системные интеграторы и консультационные компании, разработчики прикладного ПО имеют собственные методы управления рисками, которые включают в себя: • методику выделения факторов риска, • методы количественной оценки влияния факторов на такие параметры проекта, как возможное увеличение стоимости решения или времени его реализации в целом или отдельных его компонентов, • подходы к снижению влияния факторов риска на успех проекта. На рис. 36 приведена типовая схема процедуры управления рисками. Для минимизации бизнес-рисков используются следующие подходы: • минимизация инвестиционных рисков, • максимально возможная стандартизация всех компонентов решения. Для минимизации рисков, обусловленных нарушением графика инвестиций, целесообразно планировать процесс автоматизации так, чтобы на каждом этапе иметь пусть ограниченное, но законченное решение, которое ценно само по себе. Например, автоматизация процесса управления складом. Примерный перечень стандартизируемых компонентов имеет следующий вид: • автоматизируемые бизнес-процессы предприятия, • процессы самой системы, • прикладное ПО, • стандарты СУБД, операционные системы, сетевые протоколы и т. д., • стандарты на оборудование, • стандарты на рабочие станции. Крайне желательно, чтобы структура автоматизируемых бизнес-процессов предприятия удовлетворяла общепринятым рекомендациям (например, MRPJI — ERP, которые в настоящее время стали практически стандартами де-факто), а также совокупности государственных и отраслевых стандартов. Для прикладного ПО с целью Рис.36 снижения рисков желательно создать набор стандартов в плане архитектуры приложений, шлюзов и интерфейсов, включая графический интерфейс пользователя. На уровне СУБД целесообразно определить требования к интерфейсам, необходимость поддержки распределенности, Internet-приложений. Аналогичным образом необходимо сформировать весь спектр стандартов от уровня операционных систем до телекоммуникаций. Заложенная изначально в решение поддержка стандартов в дальнейшем позволит, затрачивая минимальные средства, наращивать функциональные возможности системы. Для минимизации технических рисков, как правило, рекомендуется использование поэтапного подхода: • составление плана — графика работ таким образом, чтобы работы, связанные с наибольшим риском, выполнялись на возможно ранних этапах, • применение моделирования, создание стендов и макетов для апробирования технических решений, • разработка альтернативных вариантов, для исключения фактора риска. Снижение рисков управления достигается применением жестких стандартов на управление проектом в части планирования, документирования хода проекта, процедур контроля исполнения и управления изменениями. Минимизация инвестиционных рисков Для выработки требований по защите инвестиций целесообразно выделить следующие объекты затрат: • процесс создания системы, • оборудование, • программное обеспечение, • персонал, • управление задачами. Ниже представлены основные требования, направленные на повышение рентабельности функционирования информационной системы и обеспечение ее развития при сохранении вложенных средств. Процесс создания информационной системы. 1. Выбор информационной системы должен соответствовать плану стратегического развития фирмы. При этом должны быть определены: • стратегия развития бизнеса, основанная на долгосрочном предвидении состояния рынка и отрасли в сочетании со стратегией информатизации, • существенные проблемы, которые нужно решить, • план и подход к решению проблем (план развития информатизации), • мероприятия по обеспечению качества управления реализацией плана развития информатизации, • результаты внедрения, которые должны соответствовать целям предприятия. Расплывчатые требования к проектируемой информационной системе, неадекватное макетирование и тестирование рабочей модели могут свести на нет все потенциальные преимущества, которые предлагает система для предприятия, привести к значительным затратам при эксплуатации системы. 2. Соблюдение мер по защите информационной системы. Здесь под защитой надо понимать защиту от сбоев, вызванных дефектами проектирования системы. Например, неверная схема организации электропитания, отсутствие надлежащих мер по обеспечению секретности, система контроля за целостностью данных плюс защита от несанкционированного доступа, а также кражи как информации, так и техники. Приобретаемое оборудование должно удовлетворять следующим требованиям: 1.Покрывать в течение двух лет ожидаемые технические потребности. 2.Единая технология и взаимозаменяемость компонент оборудования должны обеспечивать переход на оборудование более высокого класса без замены его компонентов. 3. Модульность архитектуры. Обеспечение модульности архитектуры дает возможность наращивать мощность по мере необходимости и внедрять новые разработки по мере их появления на рынке. 4. Поддержка международных и национальных стандартов. пользователи не оказываются «запертыми в ловушку» закрытых систем, где они имеют ограниченный выбор возможностей за более высокую цену. Стандарты обеспечивают широкий выбор приложений, совместимость различных версий, возможность взаимодействия с другими вычислительными средами, доступ к таким средам, где следование определенным стандартам, например Федеральному руководству по безопасности, является необходимым условием. Такими стандартами, например, могут быть стандарты интерфейсов, стандарты управления питанием, графические стандарты, стандарты настольной среды, стандарты сетевого взаимодействия, объектные стандарты и др. 5. Возможность поддержки широкого спектра компьютерных Выполнение данного условия позволяет обеспечить возможность работы в неоднородных вычислительных средах. 6.Простота установки и смены компонентов. 7.Адекватность возможности оборудования рабочим функциям персонала. Одной из основных ошибок при проектировании информационной системы является ориентация на среднего пользователя, вследствие чего происходит непрогнозируемый рост расходов на ИТ. Это приводит к тому, что большинство пользователей получает усредненную по корпоративному стандарту производительности технику, хотя в их функции входит только набор текста по форме, а возможности компьютеров используются в лучшем случае на 10%. В то же время пользователи, которым требуется максимальная производительность, могут не получить технику, адекватную их рабочим функциям. Поэтому Gartner Group рекомендует ориентироваться на детализацию выполняемых работниками функций и осуществлять подбор техники, исходя из индивидуальных потребностей, а не усредненных показателей, и предлагает свою упрощенную градацию пользователей по выполняемым функциям: • работники, которые выполняют критические и уникальные для предприятия задачи, работая с жизненно важными данными. Кроме менеджеров высшего уровня, финансовых служб, например, сюда входит и административный ИТ-персонал. Требования к техническому оснащению и сервису максимальные. Высока и стоимость времени простоя; • мобильные работники, которые часто находятся в поездках. Обычно работают с очень хрупкой и дорогой техникой. Требования к сервисному обслуживанию, поддержке и оборудованию также высоки. Стоимость времени простоя максимальна; • работники, которые занимаются обработкой информации. Наиболее размытая категория. Стоимость времени простоя может сильно варьироваться, хотя в большинстве случаев она высока; • работники, которые осуществляют механический ввод информации в систему посредством форм. Число рабочих функций ограничено одной-двумя. Наименее критическая часть пользователей в смысле времени простоя, доставляющая, однако, максимум проблем обслуживающему персоналу.
8.Наличие средств взаимодействия с мобильным пользователем. 9.Поддержка любой системой средств сетевого управления. 10. Расширенные гарантии и пожизненная поддержка производителя и т. д. Приобретаемое программное обеспечение должно обладать следующими характеристиками: 1. Модульность. Выполнение условия позволяет снизить расходы при изменении функциональных возможностей системы за счет варьирования конфигураций ее отдельных элементов. 2. Открытость. Требование направлено на обеспечение возможности системы взаимодействовать с другим программным обеспечением по определенным стандартам. 3.Бинарная совместимость с более ранними приложениями, что позволяет взаимодействовать с унаследованными системами. 4.Масштабируемость ПО для широкого спектра системных конфигураций от изоморфной рабочей станции до корпоративной информационной системы. 5.Независимость от платформ. Ограниченное одной платформой приложение налагает ограничения на приобретение систем в будущем. Время от времени компании по ряду причин (производительность, масштабируемость, стоимость и т. д.) меняют имеющиеся операционные системы или сетевые операционные системы на другие. При изменении платформы большинство компаний рассчитывают перенести имеющиеся приложения со старой платформы на новую. При этом приложения, построенные на основе независимой от платформ системы, могут быть сразу же использованы на новой платформе. Приложения, которые привязаны к операционной системе или сетевой операционной системе, в таком случае необходимо переписывать или даже полностью заменять. Если стоимость переписывания или замены приложений превышает доход от предполагаемых инвестиций в новую платформу, компания вынуждена сохранить свою далеко не оптимальную операционную среду. 6. Соответствие нормативной конфигурации компьютера. Большинство организаций используют различные модели компьютеров разных производителей. Этим моделям предварительно задана конфигурация без учета специфики пользователя. Кроме того, они могут отличаться и по составу комплектующих. Через какое-то время, когда потребуется добавление или обновление драйверов и приложений, соответственно резко возрастут временные и финансовые затраты. 7. Совместимость с приложениями инфраструктуры, объединяю- Деловые организации уже раскрыли потенциальные возможности обработки данных в масштабе нескольких предприятий. Построив приложения на основе указанной инфраструктуры, компании всего мира смогли получить неожиданно высокие доходы по своим инвестициям в информационные технологии. 8. Наличие встроенной диагностики вирусов на клиентских мес- На предприятии достаточно одной успешной вирусной атаки, чтобы восстановление информационной структуры «съело» не только годовой бюджет на информационные технологии, но и всю прибыль предприятия. 9. Наличие эффективной системы восстановления частичной ра- При создании автоматизированной системы управления предприятием должны быть инициированы следующие процессы работы с персоналом: 1. Процесс обучения персонала, который должен быть направлен Одним из известных способов является использование средств мультимедиа. При простом обучении в классной комнате воспринимается и запоминается 10% материала. При использовании аудиовизуального ряда восприятие увеличивается до 50—80% общего объема материала. 2.Пользователи должны иметь доступ только к тем программам и функциям, которые необходимы для выполнения рабочих обязанностей. 3.Регулярное обучение пользователей эффективным методам работы с системой и приложениями. Наиболее существенная часть стоимости владения персональным компьютером связана с трудовыми затратами. Большинство проблем пользователя требуют прямого участия администратора в настройке компьютера пользователя, что увеличивает трудовые затраты административного персонала. Примеры: неосторожное удаление системных файлов пользователем, изменение конфигурации системы, инсталляция дополнительных программ, приводящая к конфликтам с уже используемым программным обеспечением, непроизводительные действия конечного пользователя, вернее, время, на них затраченное. Регулярное обучение пользователей позволяет снизить эти издержки. 4. Обучение должно предусматривать преемственность версий. Это позволит обеспечить минимальную потребность в переквалификации конечных пользователей при переходе на новую технику. 5.Регулярное обучение (и сертификация) административного персонала технологиям, используемым в сети. 6.Наличие мотивации у административного персонала для предоставления высокого уровня сервиса и т. д. конфигурации системы, инсталляция дополнительных программ, приводящая к конфликтам с уже используемым программным обеспечением, непроизводительные действия конечного пользователя, вернее, время, на них затраченное. Регулярное обучение пользователей позволяет снизить эти издержки. 4. Обучение должно предусматривать преемственность версий. Это позволит обеспечить минимальную потребность в переквалификации конечных пользователей при переходе на новую технику. 5.Регулярное обучение (и сертификация) административного персонала технологиям, используемым в сети. 6.Наличие мотивации у административного персонала для предоставления высокого уровня сервиса и т. д.
Некоторые рекомендации по выбору системы Проблемы выбора системы автоматизации управления предприятием возникают практически всегда, когда руководство, ощущая потребность в современном инструменте управления, в то же время не может четко сформулировать основные требования к системе. Как правило, руководитель предприятия должен иметь необходимую информацию о реальном положении дел в организации. Обычно к такой информации относятся наиболее «проблемные» места: неконтролируемые действия персонала (элементарное воровство), потери от недостаточно оперативного реагирования на изменение ситуации внутри и вне предприятия (изменение спроса, наличие значительного уровня товарно-материальных запасов, несвоевременная информация о финансовых операциях и т. п.), проблемы с организацией бухгалтерского учета и многие другие. При этом на свет рождается распоряжение специалистам отдела АСУ подыскать «подходящую» систему, и хорошо, если при этом сообщаются хотя бы ориентировочные финансовые параметры. Что происходит дальше, представить не сложно. Отдел АСУ находит систему, удовлетворяющую текущим требованиям. Если она подходит по стоимости и характеристикам, то через некоторое время персонал предприятия начинает работать уже в новой системе. Однако у директора появляются новые проблемы, и вновь отдел АСУ занимается поиском системы. Проходит небольшое время, и в организации начинают параллельно работать несколько различных систем, которые могут дублировать друг друга. Пользователи систем, ввиду разрозненности решений, вынуждены вести параллельный учет как при помощи программных средств, так и проверенным способом — вручную. В результате нагрузка возрастает, появляются задержки с вводом данных в информационную систему, и через некоторое время оперативность и достоверность информации, получаемой руководителем из информационной системы, уже не больше, чем была раньше, до «информатизации предприятия». Директор начинает проявлять недовольство своим персоналом, сотрудники — отделом АСУ, а отдел АСУ в сердцах клянет своего начальника и весь белый свет в придачу. А ведь многих ошибок можно было избежать гораздо раньше. Все дело в том, что ни директор предприятия, ни начальник отдела АСУ не вспоминали о критериях выбора системы автоматизации управления предприятием. Но даже если они имеют некоторое представление об этих критериях, то возникает риск преобладания одного из них над другими при принятии решения о выборе. Рассмотрим возможные последствия, к которым может привести подобное преобладание. Выбор возможного поставщика системы. Самая большая проблема может возникнуть у предприятия при выборе фирмы. Надо выбрать такую, которая не исчезнет через некоторое время. При этом надеяться на нормальное сопровождение, а уж тем более на переход к новым версиям программного продукта не приходится. Малейшее изменение российского законодательства — и надо покупать новую систему! Но, во-первых, на отечественном рынке существует большое количество довольно устойчивых и хорошо себя зарекомендовавших компаний, занимающихся разработкой систем автоматизации управления, а во-вторых, даже при работе с незнакомой компанией при покупке системы можно получить также и все исходные коды. Это обязывает содержать в своем штате несколько квалифицированных программистов, но зато снимает многие проблемы с сопровождением и внедрением системы. Поиск информации и удобство работы пользователей. Простота и удобство работы иногда могут оказаться решающим фактором при выборе системы, особенно если сравнивается несколько практически аналогичных программных продуктов. Кроме того, данный критерий косвенно свидетельствует о квалификации компании-разработчика. Гибкость системы является важным критерием ее выбора в том случае, если предприятие не собирается стоять на месте, т. е. если оно планирует развиваться, совершенствовать свою деятельность или просто функционирует в условиях постоянного изменения внешних условий (например, отечественного законодательства). Отсутствие гибкости у системы приводит к необходимости постоянного привлечения дорогостоящих специалистов фирмы-разработчика или компании-интегратора для настройки системы автоматизации управления предприятием под меняющиеся потребности деятельности. Такое положение может свести на нет весь финансовый эффект от внедрения системы. О легкости внедрения имеет смысл говорить в том случае, если предприятие жестко ограничено в конечных сроках и силах, необходимых для приведения системы в рабочее состояние. Однако забывать об этом критерии ни в коем случае нельзя, иначе внедрение автоматизированной системы рискует превратиться в бесконечный процесс. Тиражируемое™ системы (или, другими словами, количество ее внедрений) является серьезным аргументом, который помогает принять окончательное решение при выборе системы автоматизации. Так, если система не привлекла внимания ни одного из предприятий (а желательно, чтобы она была внедрена на предприятии аналогичного профиля), это должно по крайней мере насторожить. А если система внедрена, то общение с персоналом организации, в которой она успешно эксплуатируется, позволит избежать возможных ошибок. Таким образом, выбор системы автоматизации управления предприятием — это непростая задача, сложность которой может возрастать с ростом масштабов предприятия, и осуществлять его должны квалифицированные специалисты в соответствии с реальными потребностями организации. Один из эффективных способов принятия решений заключается в ранжировании используемых критериев по их важности. Ниже приводится несколько конкретных рекомендаций по принятию решений при выборе системы. Заказная или адаптированная система Основные аргументы за и против этих вариантов приведены в табл. 12. Практика показывает, что выбор варианта заказной системы оправдан практически только в двух случаях: • при уникальности автоматизируемых процессов, • при отсутствии на рынке требуемой системы. Как правило, такие ситуации возникают при автоматизации деятельности органов государственного управления, функции которых уникальны по определению, или корпораций, ведущих специфический бизнес, например брокерский. Есть, правда, и другой предельный случай: небольшое предприятие, отсутствие средств на закупку готовой системы, приводящее к тому, что один из сотрудников, знающих программирование, пишет в свободное время эту систему сам. Отечественная или зарубежная система Существуют два полярных мнения: 1)сколько бы ни стоила отечественная система, она предпочтительнее импортной, внедрение которой обходится несравнимо дороже. Кроме того, отечественные системы лучше приспособлены к условиям российского бизнеса; 2)единственными системами, которые позволяют полностью автоматизировать все аспекты управления предприятием, являются зарубежные системы типа ERP. Поэтому, несмотря на их более высокую стоимость, предприятиям следует выбирать именно ERP-си-стемы, жизнеспособность которых подтверждена мировым опытом. Обобщая эти два мнения, можно сказать, что в данном случае определяющими являются следующие критерии: • функциональная полнота, • «функциональная стоимость», т. е. доли используемых клиентом возможностей системы за потраченные им деньги [124]. Уровень системы К сожалению, для многих руководителей наиболее часто первым и практически единственным критерием служат затраты на создание системы. Иногда затраты на создание ассоциируются только со стоимостью программно-аппаратных средств. Однако такой подход может привести к покупке очередной коробки, которая будет пылиться на полке, или, в лучшем случае, к установке системы только в отделе АСУ предприятия. Функциональная полнота предлагаемого решения, как уже было показано выше, — один из важнейших критериев, на основании которых необходимо производить отбор. Выбор системы, которая обладает ограниченным набором возможностей, приведет к тому, что предприятие через некоторое время будет вынуждено затратить, возможно, гораздо большие усилия на решение оставшейся части проблем. Поэтому единственно правильным выходом изданной ситуации является рассмотрение функциональных возможностей систем автоматизации управления предприятием в свете принятой стратегии организации и, в частности, стратегии автоматизации. Еще одним подводным камнем является практически повсеместно встречающееся несоответствие рекламных заверений компаний-произво дителей фактическим возможностям систем. Однако и это препятствие легко обойти, так как многие компании-производители кроме демонстрации возможностей своих программных продуктов могут поставить их на предприятие для опытной эксплуатации. При выборе системы среднего и высокого уровня необходимо быть готовым к проведению реорганизации предприятия, что связано с дополнительными затратами времени и средств. Успех реорганизации в первую очередь определяется позицией руководства. Таким образом, при выборе уровня системы основными критериями являются: • функциональная полнота, • готовность руководства к реорганизации бизнес-процессов.
УПРАВЛЕНИЕ ПРОЦЕССОМ ВНЕДРЕНИЯ И ЭКСПЛУАТАЦИИ
Типовой план внедрения В данном разделе приведен план внедрения системы MRPII/ ERP и других технологий в организационных системах. Он включает 16 этапов, проверенных опытом тысяч компаний за 20 лет. Впервые подобный план был создан в компании Oliver Wight для внедрения первых версий MRPII. Опыт показывает, что данной стратегии придерживаются в той или иной степени практически все фирмы. На рис. 37 приведен типовой план. Ниже приведено описание этапов. 1. Предварительное обследование и оценка состояния Цель этапа — установить, в каком состоянии находится предприятие. Полезно приглашение внешних консультантов. Результаты: краткосрочный план действий, определение возможных направлений работ и рекомендации по стратегии внедрения. 2. Предварительная переподготовка Цель — дать ведущим менеджерам представление о том, что включает в себя процесс внедрения. Дело в том, что надо преодолеть различия в понимании процесса разными категориями сотрудников. Некоторые считают, что MRPH/ERP — это компьютерная система. Другие видят ее как систему управления производством и запасами. Третьи — как систему, объединяющую подразделения. Для руководителей важно прийти к единому пониманию будущего эффекта и необходимых ресурсов. Затем среднее звено отправляется на более детализированную переподготовку. Эти сотрудники будут играть важную роль во всей деятельности, поэтому каждый должен иметь понимание внедряемой технологии. 3. Техническое задание Техническое задание включает в себя анализ проблемы, план, подход к решению проблемы построения системы. Процесс создания ТЗ дает уверенность в долгосрочных планах. 4. Технико-экономическое обоснование — ТЭО (анализ «затра- Анализ «затраты—эффект» позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений. Он показывает экономический эффект: рост производительности, снижение затрат и т. п. Объекты анализа: затраты на внедрение компьютерных систем (в том числе конкретных подсистем, например бухучета и поддержку математического обеспечения), образование и т. п. 5. Организация проекта Существуют три уровня организации проекта. Разумеется, все уровни используются на больших предприятиях. Ниже представлен пример для предприятия с численностью 10 тыс. работающих. Управляющий комитет — руководитель предприятия и его заместители. Регулярные совещания 1—2 раза в месяц. Рабочий комитет — управленцы высокого уровня, которые встречаются один раз в неделю для выработки политики, решений по наиболее важным проблемам, отслеживания результатов. Рабочая команда по внедрению разбивается на логические группы по подразделениям, производственным направлениям и программам внутри компании. Команда ответственна за ежедневное управление проектом. Осуществляет контроль на уровне фирмы и ее отделов. В нее входят специалисты в различных областях. Члены команды могут работать по отдельным задачам. Оптимальное число людей в команде — 6—7 человек (не более 10). Ниже более подробно описаны функции организаторов проекта.
Управляющий комитет определяет стратегию, ресурсы, занимается управлением проектом, принимает основные решения. Если возникает проблема, то рабочая команда входит в комитет с предложениями по ее решению. Рабочий комитет — координатор команд. В малых фирмах не нужен. Рабочий комитет решает вопросы, требующие согласования позиций групп. Руководитель проекта занят только проектом (за исключением малых фирм. Он является членом управляющего комитета и служит интерфейсом между управляющим и рабочим комитетами. Исполнительный директор представляет группу высших управленцев и несет персональную ответственность за успех внедрения. Группы улучшения качества управления. Это малые группы, предназначенные для решения различных задач. Задачи могут включать обследование перед внедрением, разработку процедур ведения баз данных, совершенствования учета и т. п. В итоге распределение работ распределяет и ответственность. Одна из первых целей внедрения — вовлечь людей в принятие ответственности за изменения и новый способ ведения дел. Работа групп координируется во избежание конфликтов и дублирования. 6. Выработка целей Этот шаг определяет качественные и количественные ожидаемые результаты. Важно ясное их описание. Цели описываются конкретно: «Мы ожидаем, что улучшение в обслуживании заказчиков составляет 75—95%. Кроме того, мы ожидаем снижения запасов на 30%, на 11% уменьшение затрат на материалы...» 7. ТЗ на управление процессами Это следующий уровень детализации. ТЗ содержит описание планируемых способов развития предприятия. В более развернутом виде ТЗ на управление процессами может выглядеть как структурная схема новой системы. 8. Начальная переподготовка Цель — переподготовка сотрудников, которые затем будут работать по внедрению системы. Пример фирмы General Dynamics Land Systems — хорошая иллюстрация процесса обучения. В компании были организованы недельные курсы для высшего персонала по MRPH. Для технических руководителей — более подробные курсы по MRPH. При этом фирма использовала своих управленцев для обучения людей, так что шла передача знаний и информации от управленцев — производственникам. Важно, чтобы персонал видел, что менеджеры понимают предмет, знание которого будут требовать с сотрудников. Кроме того, в фирме должны быть выделены предметные эксперты. Это люди, которые знают фирму лучше, чем кто-либо другой, и смогут стать лучшими преподавателями. 9. Планирование и управление верхнего уровня Этот шаг в ERP, MRPH или JIT рекомендуется в качестве начального при построении системы. Такое начало процесса не требует значительных затрат, но дает большой эффект. Если этого не сделать, то неустойчивость планов высокого уровня приведет к лавинообразному эффекту: люди утратят веру в информацию и возродят неформальную систему. 10. Управление данными Есть два типа данных — первостепенные и второстепенные, нестрогие. Первостепенные данные — это данные, неточность которых недопустима: данные о запасах, состав изделия и применяемость, технология (описания), маршрутные технологии. Если неточны данные о запасах, тогда неверно и планирование. Если спланированные заказы неверны, то последующие решения тем более неверны. Следствием ошибок в информации о запасах может стать создание сотен неправильных позиций. Если состав изделия включает один предмет, а в действительности используется другой, то можно ожидать одно из последствий: имеется предмет, который не нужен; дефицит нужных предметов; дефицит обнаруживается в последнюю минуту и т. п. Результат один — дата выпуска сорвана, происходит возврат к неформальной системе. Если маршрутные технологии неточны — это означает, что последовательность операций неправильна; рабочие центры заданы неверно или нормы времени существенно неточны. Все это серьезно влияет на SFC (управление цехом) и планирование потребных мощностей. Минимальный уровень точности данных для современных систем АСУП составляет: запасы — 95%; состав изделия и применяемость — 98%; маршрутные технологии — 95%. Обеспечение требуемой точности данных — наиболее трудоемкая часть работы по внедрению. Есть типовой набор действий, позволяющих достичь требуемой точности. Переподготовка персонала — первый обязательный шаг. Люди должны понимать, почему важно иметь точную информацию. Ответственность за точность информации должна быть индивидуальной и коллективной (по подразделениям). Обеспечение инструментальными средствами. Нужна простая в использовании автоматизированная система с быстрым и разграниченным доступом. Контроль за достижением точности. Методы контроля могут быть различными. Для контроля записей о запасах чаще всего применяется инвентаризация. Выборочные позиции периодически подсчитываются и сравниваются с наличным количеством. Существует несколько различных методов проверки точности информации о составе изделий и применяемости материалов, например анализ внеплановых отпусков/поступлений материальных ресурсов или аудит. Анализ наиболее удобен для контроля производства сборочных изделий. Материальные ресурсы, отпускаемые в производство, определяются составом изделий и применяемостью. Любые дополнительные позиции, которые необходимы, или любые позиции, которые остались после производства продукции, указывают на возможную неточность информации о составе изделия. При аудите берется состав изделия и анализируется его точность. Метод аудита вполне пригоден для проверки информации о маршрутах. Главная цель этих проверок — исключение причин ошибок. Стратегия повышения точности информации та же, что и стратегия повышения качества продукции. Информация — это та же продукция со своими поставщиками и потребителями. Стратегия заключается в том, чтобы выявить причины проблемы и устранить их. Второстепенные данные. Это параметры заказа, производственные циклы, страховой уровень запасов на складе. Если точность второстепенных данных невысока, риск разрушить формальную систему невелик. Для этого типа данных целесообразно принять тактику изменения их в ходе управления. Этого может требовать и логика управления, например размер партии может со временем изменяться. 11. Одновременное внедрение различных технологий организа- Как правило, внедряется сразу несколько новых технологий управления: JIT, работа с кадрами, общий контроль качества, САПР и т. п. 12. Программное обеспечение (ПО) Хотя ПО является основой информационных технологий, хорошее ПО еще не гарантирует высоких результатов. Как отмечено выше, к эффективным результатам приводит прежде всего хороший менеджмент. На современном рынке имеется проверенное практикой ПО для систем ERP. Выбор пакета ПО для больших систем сам по себе является непростой задачей. Задача усложняется, когда речь идет о выборе зарубежной базовой системы для российского предприятия. Этот выбор является одним из наиболее важных промежуточных результатов работы руководителей и проектантов системы. 13. Опытный пример Есть три способа начала использования новой системы: /. Параллельная стратегия — для случая, когда старую работающую систему необходимо заменить новой. Например, п/с «Зарплата». Одновременно работают старая (ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, можно переходить на новую систему. Проблема в том, что большинство предприятий, внедряющих АСУП, заменяют программным обеспечением неавтоматизированный вариант, а не одну часть программного обеспечения другой. 2. «Скачок». Эта стратегия привлекательна, но мы бы ее не рекомендовали. «Скачок» означает, что прежняя система работала еще в пятницу, а в понедельник начали работать по новой системе. Некоторые считают, что такая позиция заставляет всех «тонуть и всплывать» с понедельника. Но в действительности, может утонуть все дело. Если данные не столь точны, как хотелось бы, если люди не обучены, тогда есть риск ввергнуться в хаос, сорвать поставки и финансовые расчеты. 3. Опытная эксплуатация «пилотного проекта» — это тактика «скачка», но применяемая к ограниченному числу изделий. Область применения стратегии — малый участок деятельности. Такой подход наиболее надежен, он снижает риск, и сегодня практически все фирмы применяют эту тактику. 4. «Узкое место» — это наиболее критичная малая часть производственного процесса. При внедрении «узкого места» план внедрения выполняется только для «узкого места» и для людей, работающих в нем. Точность данных повышается только для изделий в этом «узком месте»; переподготовка — только для людей, работающих в нем; анализ «затраты—эффект» делается только для него и т. д. При стратегии «узкого места» объем работ уменьшается значительно, и при заданных ресурсах «узкое место» может быть завершено в более короткие сроки, чем внедрение во всей фирме. Свойство этой стратегии — сосредоточение на «узком месте» в производственном процессе — урощает внедрение. Группе в 10— 12 человек проще сконцентрироваться на внедрении новой системы в одном сегменте бизнеса, чем 200 людям внедрять систему на всей фирме. «Узкое место» служит испытательным полигоном для дальнейших работ. Оно может явиться успешным примером, помогающим внедрению во всей фирме. Опыт показывает, что во многих случаях можно за 3—5 месяцев «расшить узкое место» и быстро достичь намеченных результатов. 14. Получение результатов Как узнать, что «пилот» работает? Как определить: продолжать или заканчивать? На эти и многие другие вопросы можно получить ответ, оценивая результаты. Большинство показателей связано с целями, установленными в ходе шага 6. 15. Анализ текущего состояния Если на первом этапе деятельности анализ определял возможные улучшения, открыв последовательность работ по внедрению, то анализ текущего состояния выявляет, какие задания выполнялись хорошо (например, достигнута высокая точность данных), а какие плохо (например, объемное планирование или составление план-графика). Затем можно сфокусировать внимание на этих проблемах и приложить усилия для их разрешения. Таким образом, анализ текущего состояния становится отправной точкой для последующих шагов совершенствования системы управления. Вообще, представленный план не должен восприниматься как способ выполнения одного проекта. Это структура непрерывного процесса совершенствования. 16. Постоянная переподготовка Неверна точка зрения, что как только начальная переподготовка завершена и фирма работает по-новому, отпадает необходимость в дальнейшей переподготовке. Кадры организации постоянно обновляются. Если сотрудники прежде не проходили переподготовку, это может привести к негативным последствиям. Кроме того, происходит постоянное изменение деятельности предприятия. Решения, которые принимались два года назад о том, как применять средства ERP, могут устареть. Наконец, есть профессиональные соображения. Часто люди стремятся повышать свой уровень узкой специализации. Переподготовка дает более широкий взгляд на проблему управления и позволяет эффективно работать с другими группами. Не нашли, что искали? Воспользуйтесь поиском:
|