Главная

Популярная публикация

Научная публикация

Случайная публикация

Обратная связь

ТОР 5 статей:

Методические подходы к анализу финансового состояния предприятия

Проблема периодизации русской литературы ХХ века. Краткая характеристика второй половины ХХ века

Ценовые и неценовые факторы

Характеристика шлифовальных кругов и ее маркировка

Служебные части речи. Предлог. Союз. Частицы

КАТЕГОРИИ:






Системы среднего уровня




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

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

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

• анализ деятельности предприятия (или предпроектное об­следование), который включает в себя сбор данных о типо­вых бизнес-процессах предприятия, его документообороте

Системы среднего уровня Появление на российском рынке систем среднего уровня было обусловлено потребностями клиентов получить в свое распоряже­ние инструмент, который давал бы возможность работать с более широким спектром задач. Некоторые из компаний постарались рас­ширить функциональные возможности своих продуктов. Кроме того, современные способы и средства разработки позволяли создавать готовые решения, охватывающие широкий круг потребностей предприятий, за довольно короткое время. Как правило, в их состав могут входить следующие подсистемы: Бухгалтерский учет, Управ­ление производством, Материально-техническое снабжение и сбыт, Планирование, Производство. Причем планирование и производ­ство реализовано в очень усеченном виде. Однако несомненным до­стоинством систем этого класса является возможность вести учет практически по всем направлениям деятельности предприятия.

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

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

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

• инсталляция и настройка системы в соответствии с результа­тами предыдущего этапа;

• обучение пользователей работе с системой;

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

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

Как показано выше, многие российские компании стали вклю­чать в состав своей продукции и возможности планирования. Одна­ко лишь зарубежные системы класса MPRII или ERP позволяют вести полнофункциональное планирование для всех ключевых биз­нес-процессов современного предприятия (в первую очередь для производства). Таким образом, на отечественном рынке появляются системы высшего класса.

 

Системы высшего уровня

Как было отмечено ранее, современные версии систем'высшего уровня обеспечивают планирование и управление всеми ресурсами организации. В системах этого класса содержится описание тысяч бизнес-процессов. И действительно, они должны обладать большой избыточностью для того, чтобы успешно использоваться на самых разных предприятиях. Количество настраиваемых параметров в та­кой системе может достигать десятков и даже сотен тысяч. Безуслов­но, возрастает и суммарная стоимость решений, причем на первое место выходят затраты, связанные с внедрением. Хотя многие ком­пании, предлагающие ERP-системы, и утверждают, что стоимость их внедрения в России равна или даже меньше стоимости лицензий на систему, реально дело обстоит несколько сложнее.

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

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

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

Однако перспектива значительных затрат не должна пугать. Ведь с внедрением ERP-системы руководители организации и ее персо­нал получают инструмент, позволяющий реально планировать и уп­равлять производством. А в условиях современной рыночной эконо­мики это может дать неоспоримое конкурентное преимущество.

Кроме того, многие ERP-системы позволяют стыковаться с CAD/CAM-системами (системами автоматизированного проекти­рования — САПР и автоматизированными системами управления технологическим процессом — АСУТП), что позволяет получить интегрированное решение, объединяющее процессы разработки, производства и поставок.

осуществить выбор технической системы, руководствуясь только критериями, приведенными в табл. 10, невозможно.

Поэтому при выборе системы потребности бизнеса, сформули­рованные в терминах бизнеса, должны быть конвертированы в тех­нические и экономические требования к системе, сформулирован­ные в соответствующих терминах:

• функциональные возможности,

• совокупная стоимость владения,

• перспективы развития, поддержки и интеграции,

• технические характеристики.

Ниже эти критерии рассматриваются подробнее.

 

Функциональные возможности


Под функциональными возможностями следует понимать соответ­ствие автоматизированной системы тем основным бизнес-функци­ям, которые существуют или планируются к внедрению в организа­ции. Иногда говорят о функциональной полноте предлагаемых ре­шений. Так, если целью организации является минимизация фи­нансовых потерь за счет оптимизации и упрощения бухгалтерского учета, то выбранная система должна обеспечивать автоматизацию процесса ведения бухгалтерского учета; если требуется достичь кон­курентного преимущества за счет сокращения сроков разработки новых видов продукции, то одно из решений может заключаться в выборе системы CAD/САМ (САПР). Для того чтобы определить до­статочность функциональных возможностей системы, необходимы два компонента:

• Стратегия развития бизнеса и контекстное описание бизнеса.

• Формализованное описание деятельности предприятия. Луч­ше всего, если это будут модели деятельности предприятия, выполненные согласно методикам структурного анализа: ди­аграммы согласно стандартам 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, могут устареть. Наконец, есть про­фессиональные соображения. Часто люди стремятся повышать свой уровень узкой специализации. Переподготовка дает более широкий взгляд на проблему управления и позволяет эффективно работать с другими группами.






Не нашли, что искали? Воспользуйтесь поиском:

vikidalka.ru - 2015-2024 год. Все права принадлежат их авторам! Нарушение авторских прав | Нарушение персональных данных