Москва 2003 в этом документе собраны фрагменты нескольких книг и пособий, которые могут быть использованы при подготовке по курсу «И - umotnas.ru o_O
Москва 2003 в этом документе собраны фрагменты нескольких книг и пособий, которые могут быть использованы при подготовке по курсу «И - umotnas.ru o_O
|
Похожие работы
|
Москва 2003 в этом документе собраны фрагменты нескольких книг и пособий, которые - страница №17/17
Глава 2УПРАВЛЕНИЕ ПРОЦЕССОМ ВНЕДРЕНИЯ И ЭКСПЛУАТАЦИИТиповой план внедренияВ данном разделе приведен план внедрения системы MRPII/ ERP и других технологий в организационных системах. Он включает 16 этапов, проверенных опытом тысяч компаний за 20 лет. Впервые подобный план был создан в компании Oliver Wight для внедрения первых версий MRPII. Опыт показывает, что дан- ной стратегии придерживаются в той или иной степени практи- чески все фирмы. На рис. 37 приведен типовой план. Ниже приведено описание этапов. Цель этапа — установить, в каком состоянии находится пред- приятие. Полезно приглашение внешних консультантов. Результа- ты: краткосрочный план действий, определение возможных на- правлений работ и рекомендации по стратегии внедрения. 2. Предварительная переподготовка Цель — дать ведущим менеджерам представление о том, что включает в себя процесс внедрения. Дело в том, что надо преодо- леть различия в понимании процесса разными категориями со- трудников. Некоторые считают, что MRPII/ERP — это компью- терная система. Другие видят ее как систему управления производ- ством и запасами. Третьи — как систему, объединяющую подраз- деления. Для руководителей важно прийти к единому пониманию будущего эффекта и необходимых ресурсов. Затем среднее звено отправляется на более детализированную переподготовку. Эти сотрудники будут играть важную роль во всей деятельности, поэтому каждый должен иметь понимание внедряе- мой технологии. 3. Техническое задание Техническое задание включает в себя анализ проблемы, план, подход к решению проблемы построения системы. Процесс созда- ния ТЗ дает уверенность в долгосрочных планах. 4. Технико-экономическое обоснование — ТЭО (анализ «затра- ты — эффект») Анализ «затраты — эффект» позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений. Он показывает экономический эффект: рост производительнос- ти, снижение затрат и т. п. Объекты анализа: затраты на внедрение компьютерных систем (в том числе конкретных подсистем, напри- мер бухучета и поддержку математического обеспечения), образо- вание и т. п. 5. Организация проекта Существуют три уровня организации проекта. Разумеется, все уровни используются на больших предприятиях. Ниже пред- ставлен пример для предприятия с численностью l0 тыс. работа- ющих. Управляющий комитет — руководитель предприятия и его заме- стители. Регулярные совещания 1 — 2 раза в месяц. Рабочий комитет — управленцы высокого уровня, которые встречаются один раз в неделю для выработки политики, решений по наиболее важным проблемам, отслеживания результатов. Рабочая команда по внедрению разбивается на логические группы по подразделениям, производственным направлениям и програм- мам внутри компании. Команда ответственна за ежедневное управ- ление проектом. Осуществляет контроль на уровне фирмы и ее отделов. В нее входят специалисты в различных областях. Члены команды могут работать по отдельным задачам. Оптимальное чис- ло людей в команде — 6 — 7 человек (не более 10). Ниже более подробно описаны функции организаторов проекта. Управляющий комитет определяет стратегию, ресурсы, занима- ется управлением проектом, принимает основные решения. Если возникает проблема, то рабочая команда входит в комитет с пред- ложениями по ее решению. Рабочий комитет — координатор команд. В малых фирмах не нужен. Рабочий комитет решает вопросы, требующие согласования позиций групп. Руководитель проекта занят только проектом (за исключени- ем малых фирм. Он является членом управляющего комитета и служит интерфейсом между управляющим и рабочим комите- тами. Исполнительный директор представляет группу высших управ- ленцев и несет персональную ответственность за успех внедре- ния. Группы улучшения качества управления. Это малые группы, пред- назначенные для решения различных задач. Задачи могут включать обследование перед внедрением, разработку процедур ведения баз данных, совершенствования учета и т. п. В итоге распределение работ распределяет и ответственность. Одна из первых целей внедрения — вовлечь людей в принятие ответ- ственности за изменения и новый способ ведения дел. Работа групп координируется во избежание конфликтов и дуб- лирования. 6. Выработка целей Этот шаг определяет качественные и количественные ожидае- мые результаты. Важно ясное их описание. Цели описываются конк- ретно: «Мы ожидаем, что улучшение в обслуживании заказчиков составляет 75 — 95%. Кроме того, мы ожидаем снижения запасов на 30%, на 11% уменьшение затрат на материалы...» 7. ТЗ на управление процессами Это следующий уровень детализации. ТЗ содержит описание пла- нируемых способов развития предприятия. В более развернутом виде ТЗ на управление процессами может выглядеть как структурная схе- ма новой системы. 8. Начальная переподготовка Цель — переподготовка сотрудников, которые затем будут рабо- тать по внедрению системы. Пример фирмы General Dynamics Land Systems — хорошая ил- люстрация процесса обучения. В компании были организованы не- дельные курсы для высшего персонала по MRPII. Для технических руководителей — более подробные курсы по MRPII. При этом фир- ма использовала своих управленцев для обучения людей, так что шла передача знаний и информации от управленцев — производ- ственникам. Важно, чтобы персонал видел, что менеджеры понимают пред- мет, знание которого будут требовать с сотрудников. Кроме того, в фирме должны быть выделены предметные экс- перты. Это люди, которые знают фирму лучше, чем кто-либо дру- гой, и смогут стать лучшими преподавателями. 9. Планирование и управление верхнего уровня Этот шаг в ERP, MRPII или JIT рекомендуется в качестве на- чального при построении системы. Такое начало процесса не требу ет значительных затрат, но дает большой эффект. Если этого не сде- лать, то неустойчивость планов высокого уровня приведет к лави- нообразному эффекту: люди утратят веру в информацию и возродят неформальную систему. 10. Управление данными Есть два типа данных — первостепенные и второстепенные, не- строгие. Первостепенные данные — это данные, неточность которых не- допустима: данные о запасах, состав изделия и применяемость, тех- нология (описания), маршрутные технологии. Если неточны данные о запасах, тогда неверно и планирование. Если спланированные заказы неверны, то последующие решения тем более неверны. Следствием ошибок в информации о запасах может стать создание сотен неправильных позиций. Если состав изделия включает один предмет, а в действитель- ности используется другой, то можно ожидать одно из послед- ствий: имеется предмет, который не нужен; дефицит нужных пред- метов; дефицит обнаруживается в последнюю минуту и т. п. Ре- зультат один — дата выпуска сорвана, происходит возврат к не- формальной системе. Если маршрутные технологии неточны — это означает, что последовательность операций неправильна; рабочие центры зада- ны неверно или нормы времени существенно неточны. Все это серьезно влияет на SFC (управление цехом) и планирование по- требных мощностей. Минимальный уровень точности данных для современных сис- тем АСУП составляет: запасы — 95%; состав изделия и применяе- мость — 98%; маршрутные технологии — 95%. Обеспечение требуемой точности данных — наиболее трудоем- кая часть работы по внедрению. Есть типовой набор действий, позволяющих достичь требуемой точности. Переподготовка персонала — первый обязательный шаг. Люди должны понимать, почему важно иметь точную информацию. Ответственность за точность информации должна быть инди- видуальной и коллективной (по подразделениям). Обеспечение инструментальными средствами. Нужна простая в использовании автоматизированная система с быстрым и разгра- ниченным доступом. Контроль за достижением точности. Методы контроля могут быть различными. Для контроля записей о запасах чаще всего при- меняется инвентаризация. Выборочные позиции периодически подсчитываются и сравниваются с наличным количеством. Существует несколько различных методов проверки точности информации о составе изделий и применяемости материалов, на- пример анализ внеплановых отпусков/поступлений материальных ресурсов или аудит. Анализ наиболее удобен для контроля производства сборочных изделий. Материальные ресурсы, отпускаемые в производство, оп- ределяются составом изделий и применяемостью. Любые дополни- тельные позиции, которые необходимы, или любые позиции, ко- торые остались после производства продукции, указывают на воз- можную неточность информации о составе изделия. При аудите берется состав изделия и анализируется его точность. Метод аудита вполне пригоден для проверки информации о марш- рутах. Главная цель этих проверок — исключение причин ошибок. Стратегия повышения точности информации та же, что и страте- гия повышения качества продукции. Информация — это та же продукция со своими поставщиками и потребителями. Стратегия заключается в том, чтобы выявить причины проблемы и устра- нить их. Второстепенные данные. Это параметры заказа, производствен- ные циклы, страховой уровень запасов на складе. Если точность второстепенных данных невысока, риск разрушить формальную систему невелик. Для этого типа данных целесообразно принять тактику изменения их в ходе управления. Этого может требовать и логика управления, например размер партии может со временем изменяться. 11. Одновременное внедрение различных технологий организа- ции и управления Как правило, внедряется сразу несколько новых технологий управления: JIT, работа с кадрами, общий контроль качества, САПР и т. п. 12. Программное обеспечение (ПО) Хотя ПО является основой информационных технологий, хо- рошее ПО еще не гарантирует высоких результатов. Как отмечено выше, к эффективным результатам приводит прежде всего хоро- ший менеджмент. На современном рынке имеется проверенное практикой ПО для систем ERP. Выбор пакета ПО для больших систем сам по себе является непростой задачей. Задача усложняет- ся, когда речь идет о выборе зарубежной базовой системы для рос- сийского предприятия. Этот выбор является одним из наиболее важных промежуточных результатов работы руководителей и про- ектантов системы. 13. Опытный пример Есть три способа начала использования новой системы: 1. Параллельная стратегия — для случая, когда старую рабо- тающую систему необходимо заменить новой. Например, п/с «Зар- плата». Одновременно работают старая (ручная) и новая система, и их выходные документы сравниваются. Если они согласуются длительное время, можно переходить на новую систему. Проблема в том, что большинство предприятий, внедряющих АСУП, заме- няют программным обеспечением неавтоматизированный вариант, а не одну часть программного обеспечения другой. 2. «Скачок». Эта стратегия привлекательна, но мы бы ее не реко- мендовали. «Скачок» означает, что прежняя система работала еще в пятницу, а в понедельник начали работать по новой системе. Неко- торые считают, что такая позиция заставляет всех «тонуть и всплы- вать» с понедельника. Но в действительности, может утонуть все дело. Если данные не столь точны, как хотелось бы, если люди не обучены, тогда есть риск ввергнуться в хаос, сорвать поставки и финансовые расчеты. 3.0пытная эксплуатация «пилотного проекта — это тактика «скачка», но применяемая к ограниченному числу изделий. Область применения стратегии — малый участок деятельности. Такой под- ход наиболее надежен, он снижает риск, и сегодня практически все фирмы применяют эту тактику. 4.«Узкое место» — это наиболее критичная малая часть про- изводственного процесса. При внедрении «узкого места» план вне- дрения выполняется только для «узкого места» и для людей, ра- ботающих в нем. Точность данных повышается только для изде- лий в этом «узком месте», переподготовка — только для людей, работающих в нем; анализ «затраты — эффект» делается только для него и т. д. При стратегии «узкого места» объем работ уменьшается значи- тельно, и при заданных ресурсах «узкое место» может быть завер- шено в более короткие сроки, чем внедрение во всей фирме. Свойство этой стратегии — сосредоточение на «узком месте» в производственном процессе — упрощает внедрение. Группе в 10— 12 человек проще сконцентрироваться на внедрении новой систе- мы в одном сегменте бизнеса, чем 200 людям внедрять систему на всей фирме. «Узкое место» служит испытательным полигоном для дальней- ших работ. Оно может явиться успешным примером, помогающим внедрению во всей фирме. Опыт показывает, что во многих случаях можно за 3 — 5 месяцев «расшить узкое место» и быстро достичь намеченных результатов. 14. Получение результатов Как узнать, что «пилот» работает? Как определить: продолжать или заканчивать? На эти и многие другие вопросы можно полу- чить ответ, оценивая результаты. Большинство показателей связа- но с целями, установленными в ходе шага 6. 15. Анализ текущего состояния Если на первом этапе деятельности анализ определял возмож- ные улучшения, открыв последовательность работ по внедрению, то анализ текущего состояния выявляет, какие задания выполня- лись хорошо (например, достигнута высокая точность данных), а какие плохо (например, объемное планирование или составление план-графика). Затем можно сфокусировать внимание на этих про- блемах и приложить усилия для их разрешения. Таким образом, анализ текущего состояния становится отправ- ной точкой для последующих шагов совершенствования системы управления. Вообще, представленный план не должен восприниматься как способ выполнения одного проекта. Это структура непрерывного процесса совершенствования. 16. Постоянная переподготовка Неверна точка зрения, что как только начальная переподготовка завершена и фирма работает по-новому, отпадает необходимость я дальнейшей переподготовке. Кадры организации постоянно обнов- ляются. Если сотрудники прежде не проходили переподготовку, это может привести к негативным последствиям. Кроме того, происходит постоянное изменение деятельности предприятия. Решения, которые принимались два года назад о том как применять средства ERP, могут устареть. Наконец, есть про- фессиональные соображения. Часто люди стремятся повышать свой уровень узкой специализации. Переподготовка дает более широкий взгляд на проблему управления и позволяет эффективно работать с другими группами. Во многих компаниях разрабатываются системы, облегчающие процесс внедрения. Элементами систем являются: заинтересован- ность, стратегическое планирование, оперативное управление про- ектом. Сопровождение и доработка системыОсновные процессы данного этапа описаны выше в разделе «Жиз- ненный цикл системы». Поэтому в настоящем разделе рассмотрен только один из процессов, а именно — доработка системы. Потреб- ность доработки системы возникает в случаях когда: • эксплуатация системы показала, что планируемые цели не достигнуты, • изменились потребности бизнеса. Таким образом, инициация процесса доработки опирается на информацию об объективных показателях эффективности системы, измеряемых в процессе ее эксплуатации. Следовательно, перед на- чалом эксплуатации должны быть сформированы набор показате- лей и периодически выполняемая процедура, с помощью которой оценивается влияние системы на деятельность предприятия. Пере- чень основных показателей, по которым оцениваются результаты эксплуатации системы, имеет следующий вид: • эксплуатационные затраты на содержание системы; • экспертные оценки персонала из числа пользователей, позволяющие определить степень соответствия возможностей системы текущим потребностям бизнеса; • динамика изменения экономических показателей предприятия: объем продаж продукции, доля рынка, номенклатура товаров. Только при наличии достаточно полного набора показателей и Вывод из эксплуатации и замещение новой системойВывод системы из эксплуатации и замещение ее новой жела- тельно производить по следующей схеме. После того как новая си- стема выбрана (момент времени X) и до момента времени 3— ввода в эксплуатацию новой системы (см. рис. 35), должна быть сформирована и реализована процедура вывода системы из эксп- луатации. Процедура должна удовлетворять следующему требова- нию: после завершения вывода системы из эксплуатации новая система должна выполнять все возложенные на нее функции. Пос- леднее, в свою очередь, подразумевает завершение следующих про- цессов: • тестирование системы в целом, • обучение пользователей и обслуживающего персонала, • конвертация всех необходимых данных, • верификация информации, генерируемой новой системой. Необходимо учитывать различия между тестированием систе- мы и верификацией генерируемой информации. Поскольку сис- тема управления является техническим продуктом высокой сте- пени сложности, в большинстве случаев единственный способ проверить корректность работы системы в целом заключается в использовании метода, часто называемого натурным эксперимен- том. То есть в процессе эксплуатации системы определяется соот- ветствие реализованных характеристик проектируемым. Для этого необходимо сравнение информации, генерируемой новой систе- мой, с некоторым эталонным значением. Иногда проверку новой системы удается выполнить с использованием ретроспективных массивов информации, сохранившихся от старой системы. В по- давляющем же большинстве случаев поставщиком эталонной ин- формации выступает старая система. Поэтому один из основных вопросов при формировании процедуры вывода старой системы и замещении ее новой — выбор длительности интервала време- ни, на котором осуществляется совместная эксплуатация двух систем. Чем этот интервал длиннее, тем с большей достовернос- тью может быть сделан вывод о достоверности информации, ге- нерируемой новой системой. С другой стороны, чем этот интер- вал короче, тем ниже дополнительные расходы, связанные с од- новременной эксплуатацией двух систем. ЧАСТЬ 5. Case studyCASE 1.Автоматизация страховой компании "Вест". Страховая компания "Вест" образована в 1993г. и с тех пор активно развивает свою деятельность в Московской области. В 1994г. для ведения бухгалтерского учета был закуплен программный продукт "Парус" (DOS- версия), а так же 5 машин IBM PC 386, что на тот момент полностью удовлетворяло потребностям фирмы. В дальнейшем образовалось 5 новых региональных филиалов компании, где так же устанавливался данный пакет и докупалась техника в соответствии с требованиями на момент закупки. Кроме того, в 1998г. в штат компании было нанято 2 программиста, которые к данному моменту завершили самостоятельную разработку специализированной страховой базы данных, использующихся во всех филиалах и головном офисе компании, и в настоящее время заняты поддержкой существующей информационной системы компании. На нынешний момент (2003г.) пакет той версии "Парус" полностью перестал отвечать требованиям фирмы, в связи с отсутствием необходимого функционала, и трудностями, связанными с обменом данными между головным офисом и филиалами. Учитывая прогнозируемый рост компании и увеличение филиальной базы, перед начальником отдела автоматизации была поставлена задача выработки вариантов автоматизации компании и выбора одного из них. Количество рабочих мест составляет 5 человек в головном офисе и по 2 человека в каждом филиале. В результате обследования рынка, были предложены следующие варианты:
Далее группе, состоящей из главного бухгалтера, начальника отдела автоматизации и программиста предлагается оценить каждый из вариантов для данной страховой фирмы и выбрать наиболее оптимальный с учетом перспективы, цены, функционала. CASE 2.Автоматизация промышленного предприятия "Фотон". Промышленное предприятие "Фотон", образованное в 1932 году, занимается производством высокоточных оптических приборов. Главные производственные мощности находятся в г. Нижний Новгород, а региональные представительства в 15 субъектах РФ. Потребители продукции (как правило) крупные промышленные предприятия в РФ и странах ближнего зарубежья. На нынешний момент (2003г.) в различных офисах компании находится более 100 персональных компьютеров (IBM-486, Pentium -133, Pentium II-333 в равных пропорциях). В 10 офисах компьютеры объединены в сеть. Программное обеспечение представляет собой разрозненные пакеты бухгалтерского, складского и кадрового учета собственной разработки начала 90х. Штат программистов состоит из 10 человек, постоянно занятых доработкой и сопровождением существующих программ. Кроме того, в каждом представительстве есть системный администратор, отвечающий за функционирование компьютеров и установленных на них программ. Проблема в данный момент состоит в том, что руководству тяжело управлять остатками готовой продукции на складах, контролировать своевременное поступление сырья и материалов, автономные, ввести контроль качества, определить на каком из технологических этапов находится та или иная партия. Годовые убытки (по оценкам аналитиков) из-за данных процессов составляют $800 тыс. В результате обследования рынка, были предложены следующие варианты автоматизации:
Далее группе, состоящей из зам. Директора по производству, главного бухгалтера и начальника отдела автоматизации предлагается оценить каждый из вариантов для данного предприятия и выбрать оптимальный с учетом перспективы, цены, функционала. CASE 3.Автоматизация торговой сети "Креон". Торговая сеть "Креон" образована в 1994 г., имеет 3 торговые площадок в г. Санкт-Петербург и 5 в городах Ленинградской области занимается, специализируется на продаже видеотехники и бытовой электроники. У "Креона" большой спектр клиентов (частные лица, фирмы). Компания располагает большим количеством (50 шт.) персональных компьютеров класса Pentium II и выше, все они связаны в сеть. На фирме установлена система документооборота (на базе Lotus Notes), единая складская программа, бухгалтерская программа 1С, программа по учету труда и заработной платы той же фирмы. В компании имеется отдел автоматизации из 5 человек (2 из них программисты, 1 WEB - дизайнер). Компания 2 раза в месяц выпускает каталог товаров, но проблема состоит в том, что их ассортимент быстро обновляется, изменяются цены, и каталог устаревает раньше, чем он доходит до потребителей. Руководство компании решило использовать технологии электронной коммерции для создания Internet каталога с системой заказов on-line. В результате обследования рынка, были предложены следующие варианты автоматизации:
Далее группе, состоящей из зам. директора по продажам, главного бухгалтера и начальника отдела автоматизации предлагается оценить каждый из вариантов для данного предприятия и выбрать наиболее оптимальный с учетом перспективы, цены, функционала. CASE 4.Автоматизация внутреннего учета в коммерческом банке "Коломенский". Коммерческий банк "Коломенский" образован в 1991 г., головной офис находится в Москве, и 15 филиалов в различных регионах. С 1997 для автоматизации банковской деятельности во всех филиалах применяется система RS-Bank 4x4. Для внутреннего (бухгалтерского и кадрового) учета в настоящий момент используется комплекс автономных программ, разработанных группой программистов банка в 1992-1993 гг. Ситуацию осложняет тот факт, что из тех разработчиков в банке никого не осталось, а возросшие с тех пор требования и введение новых форм отчетности требуют доработки данных систем. Штат программистов из 10 человек сталкивается при этом с большими трудностями, так как основная их деятельность - поддержка и доработка банковской информационной системы.
Далее группе, состоящей из директора департамента автоматизации, главного бухгалтера и 2 программистов предлагается оценить каждый из вариантов для данного предприятия и выбрать наиболее оптимальный с учетом перспективы, цены, функционала. CASE 5.Автоматизация издательской компании "Курсив". Издательская компания курсив, образованная в 1989г. выпускает специализированные издания экономической направленности (журналы, книги). На данный момент бухгалтерия компании оснащена 4-мя персональными компьютерами класса Pentium-Pentium II и бухгалтерской программой "Инфобухгалтер" приобретенной в 1995г. В штате компании состоят 3 программиста, занятых поддержкой и доработкой существующих у фирмы программ (издательских, бухгалтерских и т.д.). В 2000г. у компании появился зарубежный партнер - американский издательский дом "McGrawHill". Компания "Курсив" получила возможность для крупных инвестиций на свое развитие. Проблема состояла в том, что для этого требовалось вести кроме бухгалтерского учета в российском стандарте, еще и учет в стандарте GAAP. Кроме того, появилась необходимость детализировать существующий учет по проектам, для лучшего осуществления контроля качества. Закупленный пакет "Инфобухгалтер" такими возможностями не обладал. В результате обследования рынка, были предложены следующие варианты:
Далее группе, состоящей из главного бухгалтера, начальника отдела автоматизации и программиста предлагается оценить каждый из вариантов для данной издательской компании и выбрать наиболее оптимальный с учетом перспективы, цены, функционала. |
|
|