 |
Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | |
Нейроннoсетевые пакеты
|
|
Это широкий класс разнообразных систем, представляющих собой иерархические сетевые структуры, в узлах которых находятся так называемые нейроны. Сети тренируются на примерах, и во многих случаях дают хорошие результаты предсказаний. Основным недостатком нейронных сетей являются трудности в интерпретации результатов. Тренированная нейронная сеть представляет собой "умный черный ящик", работу которого невозможно понять и контролировать. Примеры нейронно-сетевых пакетов:
§ § BrainMaker (CSS, USA);
§ § NeuroShell (Ward Systems Group, USA);
§ § OWL (Hyperlogic, USA).
Пакеты, реализующие алгоритмы "Decision trees"
Этот метод используется только для решения задач классификации. Это является его серьезным ограничением. Результатом работы метода является иерархическая древовидная структура классификационных правил типа "IF...THEN...". Достоинством метода является естественная способность классификации на множество классов. Примеры систем:
§ § C5.0 (Rule Quest, Australia);
§ § SIPINA (University of Lyon, France);
§ § IDIS (Information Discovery, USA).
1. 1. Особенности корпоративных информационных систем
Комплексная корпоративная информационная система охватывает все бизнес-функции и все управленческие процессы корпорации. В условиях крупных предприятий и корпораций она может быть более эффективна, поскольку обеспечивает взаимодействие массовых и хорошо организованных процессов быстродействующими средствами современных информационных и телекоммуникационных технологий высокого научно-технического уровня.
Характерными особенностями крупных корпораций по сравнению с небольшими или средними предприятиями является то, что корпорации имеют более высокий уровень организации и специализации производственной и административной деятельности, значительную рассредоточенность подразделений, бóльшую массовость данных, высокий уровень регламентации не только форм исходящей внешней документации, но и внутренних управленческих документов и процессов, т.е. в целом более развитую информационно-технологическую инфраструктуру и традиции.
Таким образом, основными особенностями корпоративных информационных систем являются:
· · комплексность охвата функций управления;
· · повышенная упорядоченность деловых процессов;
· · массовость операций;
· · эффективность использования компьютерно-телекоммуникационного оборудования и программного обеспечения;
· · возможность локальной установки и внедрения отдельных частей системы;
· · адаптивность функциональной и инструментальной структуры системы к особенностям управляемого объекта;
· · возможность развития системы после ее внедрения на объекте.
2. 2. Принципы создания и требования к корпоративной информационной системе
3. 3. Управление проектами внедрения корпоративной информационной системы
Для эффективного управления проектом создания корпоративной системы финансово-экономического управления необходимо преобразовать проект в последовательность действий имеющих четко определенные цели, ограниченных во времени и допускающих независимые процедуры верификации.
Примерный перечень действий обеспечивающий успешное ведение проекта:
- сформировать управляющий комитет проекта со следующими задачами:
- принимать решения по утверждению вышеперечисленных стандартов
- принимать оперативные решения в процессе производства работ
- оценивать деятельность групп на местах и при необходимости делать оргвыводы
Процесс внедрения системы характеризуется множественным возникновением ситуаций “принятия решения”, в частности, по вопросам стандартизации процедур и справочников (см. Ниже), финансирования проекта, поощрения и наказания и т.п., что требует наличия группы “оперативного реагирования” с максимально возможными полномочиями. В принципе мониторинг процесса может осуществлять один человек, но высокая критичность принятых решений и их глубокая взаимосвязь с важнейшими бизнес-процессами компании требует принятия взвешенных решений с участием максимально возможного (с точки зрения обеспечения оперативности) числа представителей заинтересованных сторон. Однако представительство не должно превалировать над оперативностью решений, так как “ожидание консенсуса” способно уничтожить проект полностью, превратив его в саморазрушающийся “долгострой”.
- сформировать рабочую (проектную) группу в центральном офисе и на местах (филиалах) со следующими задачами:
- реализовывать процесс внедрения системы
- администрировать систему и приложения
- настраивать опции для конкретного филиала
кроме того, группа головного офиса:
- руководит и контролирует процесс в целом
- готовит вопросы на утверждение управляющего комитета
- осуществляет интерфейс с поставщиком
Минимальное количество сотрудников отдела АСУ для поддержания работоспособности системы “класса предприятия” (при односменной работе) - 5-6 человек, из них должен быть как минимум 1 - специалист - системотехник (то есть специалист по взаимодействию прикладных задач и операционно-управляющих систем), 1 - специалист по поддержке Базы Данных и программированию. Остальные - специалисты по прикладным подсистемам, сюда не входят специалисты по поддержанию работоспособности локальной вычислительной сети и технических средств связи. Также не учтен персонал, необходимый для ввода данных при “неполном охвате” или “неполной интеграции” системы, что часто встречается при отечественной любви к “экономии”. Естественно, в каждом подразделении, должны быть выделены и подготовлены “квалифицированные пользователи” обеспечивающие
При наличии сложноструктурированной или распределенной компании необходимо наличие дополнительного персонала обеспечивающего разработку и поддержание в актуальном состоянии учетных управленческих стандартов предприятия, возможно в составе экономических подразделений (бухгалтерии, планового отдела) или в виде самостоятельного подпразделения.
- сформировать корпоративные стандарты:
- финансового учета
- план счетов
- учетная политика
- шифры аналитического учета
- материального учета
- справочник-кодификатор материалов
- стандарты учета товародвижения
- финансовые документы
- учетные регистры
- сопроводительные документы
- принципы управления складскими запасами в разрезе материалов
- производственного учета
- принципы расчета себестоимости
- принципы отнесения затрат
- принципы учета вспомогательных и побочных производств
Уровень детализации корпоративных стандартов зависит от уровня интеграции бизнес- и финансовых процессов головной организации и подразделений. Наиболее простой вариант - чистый холдинг, то есть ситуация независимо хозяйствующих субьектов, итоги работы которых, как правило, консолидируются и оцениваются раз в год на уровне некоторого итогового (специального) плана балансовых счетов. Данный вариант пока редко используется в отечественной практике, так как отсутствует распространенная (принятая) методика консолидации учета, которая обеспечивала бы исключение внутрихолдинговых оборотов. Хотя в принципе российская практика учета уже позволяет использовать первый вариант - консолидацию практически стандартным (принятым на Западе) образом. Наиболее сложный вариант - “распределенное” предприятие, состоящее из нескольких территориально существенно удаленных филиалов, ведущих сложную хозяйственную деятельность, например производственных. Последний вариант особенно усложняется типично российской проблемой отсутствия хороших скоростных каналов связи.
- начать процесс
Крайне редко (точнее - практически никогда) удается обойтись в данном процессе без услуг внешних консультантов. К сожалению, отечественный рынок управленческого консалтинга только формируется и не всегда можно найти специалистов для решения конкретных частных вопросов, что часто бывает в течение проекта. При использовании же услуг западных консультантов следует иметь в виду, что стандартный (западный) проект внедрения системы исходит из некоторых предположений “по умолчанию”, вообще говоря, неверных в Российской практике, а именно:
- Руководство предприятия имеет четкие стратегические и тактические цели, в том числе в области автоматизации, в частности, любой процесс начинается с постановки целей и оценивается по достигнутым результатам, времени их достижения и затратам. (При этом существует или создается в ходе проекта адекватное письменное описание поставленных целей).
- Приоритеты находятся в области поддержки автоматизацией планирующих и управляющих технологий, а не отчетных (во всех смыслах) процедур.
- Руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления бизнесом, таких как, SIC, MRP, Supply Chain, TQM, ISO9000 и пр., и не требуется специальное обучение в случаях использования их элементов в проекте (по крайней мере, в части технологий, уже используемых заказчиком).
- Работает иерархическая структура управления - то есть распоряжения руководства безусловно обязательны для исполнителей.
- Участники проекта со стороны заказчика безусловно положительно относятся к повышению квалификации (приобретению знаний, умений) которая будет происходить в связи с выполнением проекта.
- При необходимости может быть произведена смена ролей участников проектной группы, что не должно повлиять на общий ход проекта.
Вышеперечисленные пункты, как правило, не имеют места в отечественной практике, не говоря уже о множестве других, как общих, так и специфических для конкретного предприятия отличий отечественных и западных реалий.
4. 4. Основные принципы выбора ПО для построения корпоративной информационной системы
После того, как решение о реорганизации бизнес-процессов на предприятии принято, немаловажным этапом является выбор прикладного программного обеспечения, которое будет призвано обслуживать и автоматизировать бизнес на предприятии. Многие компании используют следующий, в принципе вполне возможный вариант - они утверждают: "Мы имеем в штате программиста и он может запрограммировать все от самого начала, до самого конца на базовом языке C++ или Delphi". Конечно, такой подход имеет право на существование, поскольку найти сейчас дешевого программиста еще не составляет труда, но по мнению специалистов, он представляется бесперспективным, хотя бы по двум причинам:
· · Во-первых, на "пристойное" стандартное программное обеспечение, существующее на рынке, затрачены многие человеко-годы, причем не только на написание самих программ, но и на их отладку.
- Во-вторых, программист может в любой момент уволиться и унести с собой все "Know-how", и систему в подобных случаях зачастую приходится переписывать практически "с нуля", в то время, как с приличным поставщиком ПО вы связаны определенным договором.
Более того, как показывает практика, основные недочеты "самопальных" систем выясняются порой уже на этапах их эксплуатации и ведут к разрушительным последствиям, поскольку исправление ошибок требует больших капитало и трудовложений, а самое печальное, оказывается необходимым останавливать систему на неопределенный срок, что влечет за собой фактическое затормаживание бизнеса в ряде направлений, которые непосредственно контролировались с помощью системы, таких, например, как отгрузки или бухгалтерия.
Одной из подобных проблем, возникших в последнее время является наступление нового тысячелетия, в связи с чем на большом количестве предприятий, на которых установлены автоматизированные системы, неподдерживающие четырехзначное летоисчисление возникла необходимость в корне переписывать систему, или немедленно переходить к новой.
При выборе поставщика прикладного программного обеспечения, немаловажным фактором является его финансовая стабильность, потому как финансово нестабильный поставщик программно-прикладной составляющей ИС гораздо хуже, чем финансово нестабильный клиент. Последний омертвляет лишь оборотные средства, а первый, уйдя с рынка, омертвит капиталовложение, потому как исчезнет возможность модернизировать систему, и, в случае сбоя, ею придется заниматься незнакомым с ней специалистам.
Таким образом, можно сформировать ряд критериев, которыми следует руководствоваться при подборе системы ПО:
Первые два - почти тавтологичны:
· · Система должна быть именно системой, т.е. изменение в одной ее части (скажем, изменения запасов на складе) должны автоматически изменить показатели в других ее раздела (скажем, в бухгалтерских проводках); это свойство системы принято называть интегрируемостью.
- Процедуры в автоматизированных системах должны быть действительно автоматизированы. Дело в том, что случается, что после внедрения системы, количество процедур не уменьшается, просто раньше они выполнялись к примеру на бумаге, а сейчас делается все то же самое, но на компьютере.
- Система должна обеспечивать реализацию бизнес-процессов и процедур, которые существуют либо должны сужествовать. (оптимальны для конкретного предприятия)
- Система должна давать руководителю возможность получать оперативную информацию в объеме, достаточном для принятия оперативных решений.
- Система должна быть легка в обучении и использовании (дружественна), чтобы рядовой сотрудник мог научиться выполнять свои обязанности при ее помощи за максимально короткое время.
- В системе должна быть заложена возможность без помощи программиста редактировать все необходимые отчеты и документы, менять их форму и создавать собственные форматы.
- В системе должны быть заложены процедуры контроля, сводящие ошибки к минимуму.
- Система должна давать возможность отследить, кто и когда внес изменения в том или ином файле и какая запись была до этих изменений.
- В системах среднего уровня и выше, должны присутствовать надежные программы защиты данных и функции распределения прав доступа.
Системы ПО на российском рынке бывают трех уровней. На первом уровне располагаются простые системы для малого и сверхмалого бизнеса, по цене от 50 до 5000 долларов. В этом сегменте доминируют российские продукты. Их очень много, в основном это программы, предназначенные для простых бухгалтерских функций. Они имеют ограничения по количеству операций, по возможности наращивания дополнительных мощностей, по защищенности данных и другим параметрам, но зато просты в использовании и дешевы.
Второй уровень составляют системы по цене 10-80 тыс. долларов и с сопоставимыми затратами на внедрение. Большинство из них - действительно интегрированные системы, поскольку дают возможность весть одновременно и управленческий и финансовый учет. Они не так похожи друг на друга, как системы первого уровня. Например в одной из них может присутствовать модуль, разработанный специально для металлургического завода, в другой - нет, но зато могут присутствовать другие важные частности. И поэтому здесь уже не столь важен сам продукт, как то, как он внедряется, и, следовательно, на предприятии должны присутствовать квалифицированные специалисты, хорошо знающие как и бизнес компании, так и специфику ПО. В этом сегменте больше продуктов западных, нежели отечественных. Выбирая западный продукт, первым делом стоит обращать внимание на то, как он привязан к российским реалиям: к законодательству, инфляции и т.п. Здесь стоит заметить, что европейские системы лучше отвечают этим требованиям, нежели американские, так как они были изначально замешены на присущем всему в Европе многообразию, в том числе и в стандартах учета, и поэтому более гибки.
В российских системах редко встречаются такие качества, как многовалютность, соответствующая мировым стандартам и многоязычность, что может стать препятствием при работе с иностранными партнерами, инвесторами или клиентами.
Системы третьего уровня -это масштабные системы управления предприятием в целом по цене от 100 до 500 тыс. долларов (а иногда и дороже - все зависит от числа пользователей, от удаленности доступа, уровня базы данных и т.д.). В мире таких систем наберется не более десятка, в России систем такого уровня пока не создано вообще. Эти системы функционально различны: в одной может быть очень хорошо развит производственный модуль, в другой - финансовый. Одна больше подходит к нефтегазовому производству, другая к автомобилестроению. Сравнительный анализ систем такого уровня может вылиться в грандиозную работу, а для осуществления проекта внедрения, нужна целая команда из финансовых, управленческих и технических экспертов, имеющая достаточный опыт.
После того, как решение о выборе прикладного ПО на базе которого будет построена ИС принято, необходимо принять решение об аппаратной платформе. Аппаратную платформу следует выбирать проанализировав и определив перспективы развития предприятия, принимая во внимание масштаб выбранного ПО и то, планируется ли его наращивание в будущем, а также всевозможные количественные и качественные параметры, такие как количество автоматизированных рабочих мест, их функции, объемы информации, направленность ее потоков. Масштабы и мощность системы определяют уровень технического решения.
А к уровню и конкретному наполнению ИС уже могут быть применены стоимостные мерки. И следовательно, сущности, стоящие за малопонятными, но такими красивыми технологическими мерками, попадают под юрисдикцию закона по экономической целесообразности, в соответствии с которым приходится искать оптимальное решение, пройдя по острию ножа между неразумной с экономической точки зрения избыточностью и потерей капиталовложений в программно-техническую платформу.
5. 2. Принципы создания и требования к корпоративной информационной системе
6. 3. Управление проектами внедрения корпоративной информационной системы
Для эффективного управления проектом создания корпоративной системы финансово-экономического управления необходимо преобразовать проект в последовательность действий имеющих четко определенные цели, ограниченных во времени и допускающих независимые процедуры верификации.
Примерный перечень действий обеспечивающий успешное ведение проекта:
- сформировать управляющий комитет проекта со следующими задачами:
- принимать решения по утверждению вышеперечисленных стандартов
- принимать оперативные решения в процессе производства работ
- оценивать деятельность групп на местах и при необходимости делать оргвыводы
Процесс внедрения системы характеризуется множественным возникновением ситуаций “принятия решения”, в частности, по вопросам стандартизации процедур и справочников (см. Ниже), финансирования проекта, поощрения и наказания и т.п., что требует наличия группы “оперативного реагирования” с максимально возможными полномочиями. В принципе мониторинг процесса может осуществлять один человек, но высокая критичность принятых решений и их глубокая взаимосвязь с важнейшими бизнес-процессами компании требует принятия взвешенных решений с участием максимально возможного (с точки зрения обеспечения оперативности) числа представителей заинтересованных сторон. Однако представительство не должно превалировать над оперативностью решений, так как “ожидание консенсуса” способно уничтожить проект полностью, превратив его в саморазрушающийся “долгострой”.
- сформировать рабочую (проектную) группу в центральном офисе и на местах (филиалах) со следующими задачами:
- реализовывать процесс внедрения системы
- администрировать систему и приложения
- настраивать опции для конкретного филиала
кроме того, группа головного офиса:
- руководит и контролирует процесс в целом
- готовит вопросы на утверждение управляющего комитета
- осуществляет интерфейс с поставщиком
Минимальное количество сотрудников отдела АСУ для поддержания работоспособности системы “класса предприятия” (при односменной работе) - 5-6 человек, из них должен быть как минимум 1 - специалист - системотехник (то есть специалист по взаимодействию прикладных задач и операционно-управляющих систем), 1 - специалист по поддержке Базы Данных и программированию. Остальные - специалисты по прикладным подсистемам, сюда не входят специалисты по поддержанию работоспособности локальной вычислительной сети и технических средств связи. Также не учтен персонал, необходимый для ввода данных при “неполном охвате” или “неполной интеграции” системы, что часто встречается при отечественной любви к “экономии”. Естественно, в каждом подразделении, должны быть выделены и подготовлены “квалифицированные пользователи” обеспечивающие
При наличии сложноструктурированной или распределенной компании необходимо наличие дополнительного персонала обеспечивающего разработку и поддержание в актуальном состоянии учетных управленческих стандартов предприятия, возможно в составе экономических подразделений (бухгалтерии, планового отдела) или в виде самостоятельного подпразделения.
- сформировать корпоративные стандарты:
- финансового учета
- план счетов
- учетная политика
- шифры аналитического учета
- материального учета
- справочник-кодификатор материалов
- стандарты учета товародвижения
- финансовые документы
- учетные регистры
- сопроводительные документы
- принципы управления складскими запасами в разрезе материалов
- производственного учета
- принципы расчета себестоимости
- принципы отнесения затрат
- принципы учета вспомогательных и побочных производств
Уровень детализации корпоративных стандартов зависит от уровня интеграции бизнес- и финансовых процессов головной организации и подразделений. Наиболее простой вариант - чистый холдинг, то есть ситуация независимо хозяйствующих субьектов, итоги работы которых, как правило, консолидируются и оцениваются раз в год на уровне некоторого итогового (специального) плана балансовых счетов. Данный вариант пока редко используется в отечественной практике, так как отсутствует распространенная (принятая) методика консолидации учета, которая обеспечивала бы исключение внутрихолдинговых оборотов. Хотя в принципе российская практика учета уже позволяет использовать первый вариант - консолидацию практически стандартным (принятым на Западе) образом. Наиболее сложный вариант - “распределенное” предприятие, состоящее из нескольких территориально существенно удаленных филиалов, ведущих сложную хозяйственную деятельность, например производственных. Последний вариант особенно усложняется типично российской проблемой отсутствия хороших скоростных каналов связи.
- начать процесс
Крайне редко (точнее - практически никогда) удается обойтись в данном процессе без услуг внешних консультантов. К сожалению, отечественный рынок управленческого консалтинга только формируется и не всегда можно найти специалистов для решения конкретных частных вопросов, что часто бывает в течение проекта. При использовании же услуг западных консультантов следует иметь в виду, что стандартный (западный) проект внедрения системы исходит из некоторых предположений “по умолчанию”, вообще говоря, неверных в Российской практике, а именно:
- Руководство предприятия имеет четкие стратегические и тактические цели, в том числе в области автоматизации, в частности, любой процесс начинается с постановки целей и оценивается по достигнутым результатам, времени их достижения и затратам. (При этом существует или создается в ходе проекта адекватное письменное описание поставленных целей).
- Приоритеты находятся в области поддержки автоматизацией планирующих и управляющих технологий, а не отчетных (во всех смыслах) процедур.
- Руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления бизнесом, таких как, SIC, MRP, Supply Chain, TQM, ISO9000 и пр., и не требуется специальное обучение в случаях использования их элементов в проекте (по крайней мере, в части технологий, уже используемых заказчиком).
- Работает иерархическая структура управления - то есть распоряжения руководства безусловно обязательны для исполнителей.
- Участники проекта со стороны заказчика безусловно положительно относятся к повышению квалификации (приобретению знаний, умений) которая будет происходить в связи с выполнением проекта.
- При необходимости может быть произведена смена ролей участников проектной группы, что не должно повлиять на общий ход проекта.
Вышеперечисленные пункты, как правило, не имеют места в отечественной практике, не говоря уже о множестве других, как общих, так и специфических для конкретного предприятия отличий отечественных и западных реалий.
7. 4. Основные принципы выбора ПО для построения корпоративной информационной системы
После того, как решение о реорганизации бизнес-процессов на предприятии принято, немаловажным этапом является выбор прикладного программного обеспечения, которое будет призвано обслуживать и автоматизировать бизнес на предприятии. Многие компании используют следующий, в принципе вполне возможный вариант - они утверждают: "Мы имеем в штате программиста и он может запрограммировать все от самого начала, до самого конца на базовом языке C++ или Delphi". Конечно, такой подход имеет право на существование, поскольку найти сейчас дешевого программиста еще не составляет труда, но по мнению специалистов, он представляется бесперспективным, хотя бы по двум причинам:
· · Во-первых, на "пристойное" стандартное программное обеспечение, существующее на рынке, затрачены многие человеко-годы, причем не только на написание самих программ, но и на их отладку.
- Во-вторых, программист может в любой момент уволиться и унести с собой все "Know-how", и систему в подобных случаях зачастую приходится переписывать практически "с нуля", в то время, как с приличным поставщиком ПО вы связаны определенным договором.
Более того, как показывает практика, основные недочеты "самопальных" систем выясняются порой уже на этапах их эксплуатации и ведут к разрушительным последствиям, поскольку исправление ошибок требует больших капитало и трудовложений, а самое печальное, оказывается необходимым останавливать систему на неопределенный срок, что влечет за собой фактическое затормаживание бизнеса в ряде направлений, которые непосредственно контролировались с помощью системы, таких, например, как отгрузки или бухгалтерия.
Одной из подобных проблем, возникших в последнее время является наступление нового тысячелетия, в связи с чем на большом количестве предприятий, на которых установлены автоматизированные системы, неподдерживающие четырехзначное летоисчисление возникла необходимость в корне переписывать систему, или немедленно переходить к новой.
При выборе поставщика прикладного программного обеспечения, немаловажным фактором является его финансовая стабильность, потому как финансово нестабильный поставщик программно-прикладной составляющей ИС гораздо хуже, чем финансово нестабильный клиент. Последний омертвляет лишь оборотные средства, а первый, уйдя с рынка, омертвит капиталовложение, потому как исчезнет возможность модернизировать систему, и, в случае сбоя, ею придется заниматься незнакомым с ней специалистам.
Таким образом, можно сформировать ряд критериев, которыми следует руководствоваться при подборе системы ПО:
Первые два - почти тавтологичны:
· · Система должна быть именно системой, т.е. изменение в одной ее части (скажем, изменения запасов на складе) должны автоматически изменить показатели в других ее раздела (скажем, в бухгалтерских проводках); это свойство системы принято называть интегрируемостью.
- Процедуры в автоматизированных системах должны быть действительно автоматизированы. Дело в том, что случается, что после внедрения системы, количество процедур не уменьшается, просто раньше они выполнялись к примеру на бумаге, а сейчас делается все то же самое, но на компьютере.
- Система должна обеспечивать реализацию бизнес-процессов и процедур, которые существуют либо должны сужествовать. (оптимальны для конкретного предприятия)
- Система должна давать руководителю возможность получать оперативную информацию в объеме, достаточном для принятия оперативных решений.
- Система должна быть легка в обучении и использовании (дружественна), чтобы рядовой сотрудник мог научиться выполнять свои обязанности при ее помощи за максимально короткое время.
- В системе должна быть заложена возможность без помощи программиста редактировать все необходимые отчеты и документы, менять их форму и создавать собственные форматы.
- В системе должны быть заложены процедуры контроля, сводящие ошибки к минимуму.
- Система должна давать возможность отследить, кто и когда внес изменения в том или ином файле и какая запись была до этих изменений.
- В системах среднего уровня и выше, должны присутствовать надежные программы защиты данных и функции распределения прав доступа.
Системы ПО на российском рынке бывают трех уровней. На первом уровне располагаются простые системы для малого и сверхмалого бизнеса, по цене от 50 до 5000 долларов. В этом сегменте доминируют российские продукты. Их очень много, в основном это программы, предназначенные для простых бухгалтерских функций. Они имеют ограничения по количеству операций, по возможности наращивания дополнительных мощностей, по защищенности данных и другим параметрам, но зато просты в использовании и дешевы.
Второй уровень составляют системы по цене 10-80 тыс. долларов и с сопоставимыми затратами на внедрение. Большинство из них - действительно интегрированные системы, поскольку дают возможность весть одновременно и управленческий и финансовый учет. Они не так похожи друг на друга, как системы первого уровня. Например в одной из них может присутствовать модуль, разработанный специально для металлургического завода, в другой - нет, но зато могут присутствовать другие важные частности. И поэтому здесь уже не столь важен сам продукт, как то, как он внедряется, и, следовательно, на предприятии должны присутствовать квалифицированные специалисты, хорошо знающие как и бизнес компании, так и специфику ПО. В этом сегменте больше продуктов западных, нежели отечественных. Выбирая западный продукт, первым делом стоит обращать внимание на то, как он привязан к российским реалиям: к законодательству, инфляции и т.п. Здесь стоит заметить, что европейские системы лучше отвечают этим требованиям, нежели американские, так как они были изначально замешены на присущем всему в Европе многообразию, в том числе и в стандартах учета, и поэтому более гибки.
В российских системах редко встречаются такие качества, как многовалютность, соответствующая мировым стандартам и многоязычность, что может стать препятствием при работе с иностранными партнерами, инвесторами или клиентами.
Системы третьего уровня -это масштабные системы управления предприятием в целом по цене от 100 до 500 тыс. долларов (а иногда и дороже - все зависит от числа пользователей, от удаленности доступа, уровня базы данных и т.д.). В мире таких систем наберется не более десятка, в России систем такого уровня пока не создано вообще. Эти системы функционально различны: в одной может быть очень хорошо развит производственный модуль, в другой - финансовый. Одна больше подходит к нефтегазовому производству, другая к автомобилестроению. Сравнительный анализ систем такого уровня может вылиться в грандиозную работу, а для осуществления проекта внедрения, нужна целая команда из финансовых, управленческих и технических экспертов, имеющая достаточный опыт.
После того, как решение о выборе прикладного ПО на базе которого будет построена ИС принято, необходимо принять решение об аппаратной платформе. Аппаратную платформу следует выбирать проанализировав и определив перспективы развития предприятия, принимая во внимание масштаб выбранного ПО и то, планируется ли его наращивание в будущем, а также всевозможные количественные и качественные параметры, такие как количество автоматизированных рабочих мест, их функции, объемы информации, направленность ее потоков. Масштабы и мощность системы определяют уровень технического решения.
А к уровню и конкретному наполнению ИС уже могут быть применены стоимостные мерки. И следовательно, сущности, стоящие за малопонятными, но такими красивыми технологическими мерками, попадают под юрисдикцию закона по экономической целесообразности, в соответствии с которым приходится искать оптимальное решение, пройдя по острию ножа между неразумной с экономической точки зрения избыточностью и потерей капиталовложений в программно-техническую платформу.
8. 3. Управление проектами внедрения корпоративной информационной системы
Для эффективного управления проектом создания корпоративной системы финансово-экономического управления необходимо преобразовать проект в последовательность действий имеющих четко определенные цели, ограниченных во времени и допускающих независимые процедуры верификации.
Примерный перечень действий обеспечивающий успешное ведение проекта:
- сформировать управляющий комитет проекта со следующими задачами:
- принимать решения по утверждению вышеперечисленных стандартов
- принимать оперативные решения в процессе производства работ
- оценивать деятельность групп на местах и при необходимости делать оргвыводы
Процесс внедрения системы характеризуется множественным возникновением ситуаций “принятия решения”, в частности, по вопросам стандартизации процедур и справочников (см. Ниже), финансирования проекта, поощрения и наказания и т.п., что требует наличия группы “оперативного реагирования” с максимально возможными полномочиями. В принципе мониторинг процесса может осуществлять один человек, но высокая критичность принятых решений и их глубокая взаимосвязь с важнейшими бизнес-процессами компании требует принятия взвешенных решений с участием максимально возможного (с точки зрения обеспечения оперативности) числа представителей заинтересованных сторон. Однако представительство не должно превалировать над оперативностью решений, так как “ожидание консенсуса” способно уничтожить проект полностью, превратив его в саморазрушающийся “долгострой”.
- сформировать рабочую (проектную) группу в центральном офисе и на местах (филиалах) со следующими задачами:
- реализовывать процесс внедрения системы
- администрировать систему и приложения
- настраивать опции для конкретного филиала
кроме того, группа головного офиса:
- руководит и контролирует процесс в целом
- готовит вопросы на утверждение управляющего комитета
- осуществляет интерфейс с поставщиком
Минимальное количество сотрудников отдела АСУ для поддержания работоспособности системы “класса предприятия” (при односменной работе) - 5-6 человек, из них должен быть как минимум 1 - специалист - системотехник (то есть специалист по взаимодействию прикладных задач и операционно-управляющих систем), 1 - специалист по поддержке Базы Данных и программированию. Остальные - специалисты по прикладным подсистемам, сюда не входят специалисты по поддержанию работоспособности локальной вычислительной сети и технических средств связи. Также не учтен персонал, необходимый для ввода данных при “неполном охвате” или “неполной интеграции” системы, что часто встречается при отечественной любви к “экономии”. Естественно, в каждом подразделении, должны быть выделены и подготовлены “квалифицированные пользователи” обеспечивающие
При наличии сложноструктурированной или распределенной компании необходимо наличие дополнительного персонала обеспечивающего разработку и поддержание в актуальном состоянии учетных управленческих стандартов предприятия, возможно в составе экономических подразделений (бухгалтерии, планового отдела) или в виде самостоятельного подпразделения.
- сформировать корпоративные стандарты:
- финансового учета
- план счетов
- учетная политика
- шифры аналитического учета
- материального учета
- справочник-кодификатор материалов
- стандарты учета товародвижения
- финансовые документы
- учетные регистры
- сопроводительные документы
- принципы управления складскими запасами в разрезе материалов
- производственного учета
- принципы расчета себестоимости
- принципы отнесения затрат
- принципы учета вспомогательных и побочных производств
Уровень детализации корпоративных стандартов зависит от уровня интеграции бизнес- и финансовых процессов головной организации и подразделений. Наиболее простой вариант - чистый холдинг, то есть ситуация независимо хозяйствующих субьектов, итоги работы которых, как правило, консолидируются и оцениваются раз в год на уровне некоторого итогового (специального) плана балансовых счетов. Данный вариант пока редко используется в отечественной практике, так как отсутствует распространенная (принятая) методика консолидации учета, которая обеспечивала бы исключение внутрихолдинговых оборотов. Хотя в принципе российская практика учета уже позволяет использовать первый вариант - консолидацию практически стандартным (принятым на Западе) образом. Наиболее сложный вариант - “распределенное” предприятие, состоящее из нескольких территориально существенно удаленных филиалов, ведущих сложную хозяйственную деятельность, например производственных. Последний вариант особенно усложняется типично российской проблемой отсутствия хороших скоростных каналов связи.
- начать процесс
Крайне редко (точнее - практически никогда) удается обойтись в данном процессе без услуг внешних консультантов. К сожалению, отечественный рынок управленческого консалтинга только формируется и не всегда можно найти специалистов для решения конкретных частных вопросов, что часто бывает в течение проекта. При использовании же услуг западных консультантов следует иметь в виду, что стандартный (западный) проект внедрения системы исходит из некоторых предположений “по умолчанию”, вообще говоря, неверных в Российской практике, а именно:
- Руководство предприятия имеет четкие стратегические и тактические цели, в том числе в области автоматизации, в частности, любой процесс начинается с постановки целей и оценивается по достигнутым результатам, времени их достижения и затратам. (При этом существует или создается в ходе проекта адекватное письменное описание поставленных целей).
- Приоритеты находятся в области поддержки автоматизацией планирующих и управляющих технологий, а не отчетных (во всех смыслах) процедур.
- Руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления бизнесом, таких как, SIC, MRP, Supply Chain, TQM, ISO9000 и пр., и не требуется специальное обучение в случаях использования их элементов в проекте (по крайней мере, в части технологий, уже используемых заказчиком).
- Работает иерархическая структура управления - то есть распоряжения руководства безусловно обязательны для исполнителей.
- Участники проекта со стороны заказчика безусловно положительно относятся к повышению квалификации (приобретению знаний, умений) которая будет происходить в связи с выполнением проекта.
- При необходимости может быть произведена смена ролей участников проектной группы, что не должно повлиять на общий ход проекта.
Вышеперечисленные пункты, как правило, не имеют места в отечественной практике, не говоря уже о множестве других, как общих, так и специфических для конкретного предприятия отличий отечественных и западных реалий.
9. 4. Основные принципы выбора ПО для построения корпоративной информационной системы
После того, как решение о реорганизации бизнес-процессов на предприятии принято, немаловажным этапом является выбор прикладного программного обеспечения, которое будет призвано обслуживать и автоматизировать бизнес на предприятии. Многие компании используют следующий, в принципе вполне возможный вариант - они утверждают: "Мы имеем в штате программиста и он может запрограммировать все от самого начала, до самого конца на базовом языке C++ или Delphi". Конечно, такой подход имеет право на существование, поскольку найти сейчас дешевого программиста еще не составляет труда, но по мнению специалистов, он представляется бесперспективным, хотя бы по двум причинам:
· · Во-первых, на "пристойное" стандартное программное обеспечение, существующее на рынке, затрачены многие человеко-годы, причем не только на написание самих программ, но и на их отладку.
- Во-вторых, программист может в любой момент уволиться и унести с собой все "Know-how", и систему в подобных случаях зачастую приходится переписывать практически "с нуля", в то время, как с приличным поставщиком ПО вы связаны определенным договором.
Более того, как показывает практика, основные недочеты "самопальных" систем выясняются порой уже на этапах их эксплуатации и ведут к разрушительным последствиям, поскольку исправление ошибок требует больших капитало и трудовложений, а самое печальное, оказывается необходимым останавливать систему на неопределенный срок, что влечет за собой фактическое затормаживание бизнеса в ряде направлений, которые непосредственно контролировались с помощью системы, таких, например, как отгрузки или бухгалтерия.
Одной из подобных проблем, возникших в последнее время является наступление нового тысячелетия, в связи с чем на большом количестве предприятий, на которых установлены автоматизированные системы, неподдерживающие четырехзначное летоисчисление возникла необходимость в корне переписывать систему, или немедленно переходить к новой.
При выборе поставщика прикладного программного обеспечения, немаловажным фактором является его финансовая стабильность, потому как финансово нестабильный поставщик программно-прикладной составляющей ИС гораздо хуже, чем финансово нестабильный клиент. Последний омертвляет лишь оборотные средства, а первый, уйдя с рынка, омертвит капиталовложение, потому как исчезнет возможность модернизировать систему, и, в случае сбоя, ею придется заниматься незнакомым с ней специалистам.
Таким образом, можно сформировать ряд критериев, которыми следует руководствоваться при подборе системы ПО:
Первые два - почти тавтологичны:
· · Система должна быть именно системой, т.е. изменение в одной ее части (скажем, изменения запасов на складе) должны автоматически изменить показатели в других ее раздела (скажем, в бухгалтерских проводках); это свойство системы принято называть интегрируемостью.
- Процедуры в автоматизированных системах должны быть действительно автоматизированы. Дело в том, что случается, что после внедрения системы, количество процедур не уменьшается, просто раньше они выполнялись к примеру на бумаге, а сейчас делается все то же самое, но на компьютере.
- Система должна обеспечивать реализацию бизнес-процессов и процедур, которые существуют либо должны сужествовать. (оптимальны для конкретного предприятия)
- Система должна давать руководителю возможность получать оперативную информацию в объеме, достаточном для принятия оперативных решений.
- Система должна быть легка в обучении и использовании (дружественна), чтобы рядовой сотрудник мог научиться выполнять свои обязанности при ее помощи за максимально короткое время.
- В системе должна быть заложена возможность без помощи программиста редактировать все необходимые отчеты и документы, менять их форму и создавать собственные форматы.
- В системе должны быть заложены процедуры контроля, сводящие ошибки к минимуму.
- Система должна давать возможность отследить, кто и когда внес изменения в том или ином файле и какая запись была до этих изменений.
- В системах среднего уровня и выше, должны присутствовать надежные программы защиты данных и функции распределения прав доступа.
Системы ПО на российском рынке бывают трех уровней. На первом уровне располагаются простые системы для малого и сверхмалого бизнеса, по цене от 50 до 5000 долларов. В этом сегменте доминируют российские продукты. Их очень много, в основном это программы, предназначенные для простых бухгалтерских функций. Они имеют ограничения по количеству операций, по возможности наращивания дополнительных мощностей, по защищенности данных и другим параметрам, но зато просты в использовании и дешевы.
Второй уровень составляют системы по цене 10-80 тыс. долларов и с сопоставимыми затратами на внедрение. Большинство из них - действительно интегрированные системы, поскольку дают возможность весть одновременно и управленческий и финансовый учет. Они не так похожи друг на друга, как системы первого уровня. Например в одной из них может присутствовать модуль, разработанный специально для металлургического завода, в другой - нет, но зато могут присутствовать другие важные частности. И поэтому здесь уже не столь важен сам продукт, как то, как он внедряется, и, следовательно, на предприятии должны присутствовать квалифицированные специалисты, хорошо знающие как и бизнес компании, так и специфику ПО. В этом сегменте больше продуктов западных, нежели отечественных. Выбирая западный продукт, первым делом стоит обращать внимание на то, как он привязан к российским реалиям: к законодательству, инфляции и т.п. Здесь стоит заметить, что европейские системы лучше отвечают этим требованиям, нежели американские, так как они были изначально замешены на присущем всему в Европе многообразию, в том числе и в стандартах учета, и поэтому более гибки.
В российских системах редко встречаются такие качества, как многовалютность, соответствующая мировым стандартам и многоязычность, что может стать препятствием при работе с иностранными партнерами, инвесторами или клиентами.
Системы третьего уровня -это масштабные системы управления предприятием в целом по цене от 100 до 500 тыс. долларов (а иногда и дороже - все зависит от числа пользователей, от удаленности доступа, уровня базы данных и т.д.). В мире таких систем наберется не более десятка, в России систем такого уровня пока не создано вообще. Эти системы функционально различны: в одной может быть очень хорошо развит производственный модуль, в другой - финансовый. Одна больше подходит к нефтегазовому производству, другая к автомобилестроению. Сравнительный анализ систем такого уровня может вылиться в грандиозную работу, а для осуществления проекта внедрения, нужна целая команда из финансовых, управленческих и технических экспертов, имеющая достаточный опыт.
После того, как решение о выборе прикладного ПО на базе которого будет построена ИС принято, необходимо принять решение об аппаратной платформе. Аппаратную платформу следует выбирать проанализировав и определив перспективы развития предприятия, принимая во внимание масштаб выбранного ПО и то, планируется ли его наращивание в будущем, а также всевозможные количественные и качественные параметры, такие как количество автоматизированных рабочих мест, их функции, объемы информации, направленность ее потоков. Масштабы и мощность системы определяют уровень технического решения.
А к уровню и конкретному наполнению ИС уже могут быть применены стоимостные мерки. И следовательно, сущности, стоящие за малопонятными, но такими красивыми технологическими мерками, попадают под юрисдикцию закона по экономической целесообразности, в соответствии с которым приходится искать оптимальное решение, пройдя по острию ножа между неразумной с экономической точки зрения избыточностью и потерей капиталовложений в программно-техническую платформу.
10. 4. Основные принципы выбора ПО для построения корпоративной информационной системы
После того, как решение о реорганизации бизнес-процессов на предприятии принято, немаловажным этапом является выбор прикладного программного обеспечения, которое будет призвано обслуживать и автоматизировать бизнес на предприятии. Многие компании используют следующий, в принципе вполне возможный вариант - они утверждают: "Мы имеем в штате программиста и он может запрограммировать все от самого начала, до самого конца на базовом языке C++ или Delphi". Конечно, такой подход имеет право на существование, поскольку найти сейчас дешевого программиста еще не составляет труда, но по мнению специалистов, он представляется бесперспективным, хотя бы по двум причинам:
· · Во-первых, на "пристойное" стандартное программное обеспечение, существующее на рынке, затрачены многие человеко-годы, причем не только на написание самих программ, но и на их отладку.
- Во-вторых, программист может в любой момент уволиться и унести с собой все "Know-how", и систему в подобных случаях зачастую приходится переписывать практически "с нуля", в то время, как с приличным поставщиком ПО вы связаны определенным договором.
Более того, как показывает практика, основные недочеты "самопальных" систем выясняются порой уже на этапах их эксплуатации и ведут к разрушительным последствиям, поскольку исправление ошибок требует больших капитало и трудовложений, а самое печальное, оказывается необходимым останавливать систему на неопределенный срок, что влечет за собой фактическое затормаживание бизнеса в ряде направлений, которые непосредственно контролировались с помощью системы, таких, например, как отгрузки или бухгалтерия.
Одной из подобных проблем, возникших в последнее время является наступление нового тысячелетия, в связи с чем на большом количестве предприятий, на которых установлены автоматизированные системы, неподдерживающие четырехзначное летоисчисление возникла необходимость в корне переписывать систему, или немедленно переходить к новой.
При выборе поставщика прикладного программного обеспечения, немаловажным фактором является его финансовая стабильность, потому как финансово нестабильный поставщик программно-прикладной составляющей ИС гораздо хуже, чем финансово нестабильный клиент. Последний омертвляет лишь оборотные средства, а первый, уйдя с рынка, омертвит капиталовложение, потому как исчезнет возможность модернизировать систему, и, в случае сбоя, ею придется заниматься незнакомым с ней специалистам.
Таким образом, можно сформировать ряд критериев, которыми следует руководствоваться при подборе системы ПО:
Первые два - почти тавтологичны:
· · Система должна быть именно системой, т.е. изменение в одной ее части (скажем, изменения запасов на складе) должны автоматически изменить показатели в других ее раздела (скажем, в бухгалтерских проводках); это свойство системы принято называть интегрируемостью.
- Процедуры в автоматизированных системах должны быть действительно автоматизированы. Дело в том, что случается, что после внедрения системы, количество процедур не уменьшается, просто раньше они выполнялись к примеру на бумаге, а сейчас делается все то же самое, но на компьютере.
- Система должна обеспечивать реализацию бизнес-процессов и процедур, которые существуют либо должны сужествовать. (оптимальны для конкретного предприятия)
- Система должна давать руководителю возможность получать оперативную информацию в объеме, достаточном для принятия оперативных решений.
- Система должна быть легка в обучении и использовании (дружественна), чтобы рядовой сотрудник мог научиться выполнять свои обязанности при ее помощи за максимально короткое время.
- В системе должна быть заложена возможность без помощи программиста редактировать все необходимые отчеты и документы, менять их форму и создавать собственные форматы.
- В системе должны быть заложены процедуры контроля, сводящие ошибки к минимуму.
- Система должна давать возможность отследить, кто и когда внес изменения в том или ином файле и какая запись была до этих изменений.
- В системах среднего уровня и выше, должны присутствовать надежные программы защиты данных и функции распределения прав доступа.
Системы ПО на российском рынке бывают трех уровней. На первом уровне располагаются простые системы для малого и сверхмалого бизнеса, по цене от 50 до 5000 долларов. В этом сегменте доминируют российские продукты. Их очень много, в основном это программы, предназначенные для простых бухгалтерских функций. Они имеют ограничения по количеству операций, по возможности наращивания дополнительных мощностей, по защищенности данных и другим параметрам, но зато просты в использовании и дешевы.
Второй уровень составляют системы по цене 10-80 тыс. долларов и с сопоставимыми затратами на внедрение. Большинство из них - действительно интегрированные системы, поскольку дают возможность весть одновременно и управленческий и финансовый учет. Они не так похожи друг на друга, как системы первого уровня. Например в одной из них может присутствовать модуль, разработанный специально для металлургического завода, в другой - нет, но зато могут присутствовать другие важные частности. И поэтому здесь уже не столь важен сам продукт, как то, как он внедряется, и, следовательно, на предприятии должны присутствовать квалифицированные специалисты, хорошо знающие как и бизнес компании, так и специфику ПО. В этом сегменте больше продуктов западных, нежели отечественных. Выбирая западный продукт, первым делом стоит обращать внимание на то, как он привязан к российским реалиям: к законодательству, инфляции и т.п. Здесь стоит заметить, что европейские системы лучше отвечают этим требованиям, нежели американские, так как они были изначально замешены на присущем всему в Европе многообразию, в том числе и в стандартах учета, и поэтому более гибки.
В российских системах редко встречаются такие качества, как многовалютность, соответствующая мировым стандартам и многоязычность, что может стать препятствием при работе с иностранными партнерами, инвесторами или клиентами.
Системы третьего уровня -это масштабные системы управления предприятием в целом по цене от 100 до 500 тыс. долларов (а иногда и дороже - все зависит от числа пользователей, от удаленности доступа, уровня базы данных и т.д.). В мире таких систем наберется не более десятка, в России систем такого уровня пока не создано вообще. Эти системы функционально различны: в одной может быть очень хорошо развит производственный модуль, в другой - финансовый. Одна больше подходит к нефтегазовому производству, другая к автомобилестроению. Сравнительный анализ систем такого уровня может вылиться в грандиозную работу, а для осуществления проекта внедрения, нужна целая команда из финансовых, управленческих и технических экспертов, имеющая достаточный опыт.
После того, как решение о выборе прикладного ПО на базе которого будет построена ИС принято, необходимо принять решение об аппаратной платформе. Аппаратную платформу следует выбирать проанализировав и определив перспективы развития предприятия, принимая во внимание масштаб выбранного ПО и то, планируется ли его наращивание в будущем, а также всевозможные количественные и качественные параметры, такие как количество автоматизированных рабочих мест, их функции, объемы информации, направленность ее потоков. Масштабы и мощность системы определяют уровень технического решения.
А к уровню и конкретному наполнению ИС уже могут быть применены стоимостные мерки. И следовательно, сущности, стоящие за малопонятными, но такими красивыми технологическими мерками, попадают под юрисдикцию закона по экономической целесообразности, в соответствии с которым приходится искать оптимальное решение, пройдя по острию ножа между неразумной с экономической точки зрения избыточностью и потерей капиталовложений в программно-техническую платформу.
11. Корпоративные системы управления
Корпоративные информационные системы управления предприятием предназначены для управления и планирования деятельностью предприятия на уровне среднесрочного и краткосрочного планирования, а также для оперативного управления.
Задачи корпоративных систем в разрезе изделия охватывают полный «цикл жизни» изделия и выглядят, например, так:
- поддержка разработки изделия (интерфейс с системой конструирования);
- обеспечение изготовления и испытаний пилотных экземпляров;
- обеспечение изготовления опытных и установочных партий;
- обеспечение серийного и заказного производства;
- поддержка изготовления модификаций и клонов;
- организация выпуска семейства изделий;
- снятие с производства изделий или замена вновь разработанными (сконструированными).
Такие системы получили название ERP систем (Enterprise Resource Planning). В общем виде, задачи, которые решаются такими системами на предприятии можно представить в виде рисунка 1.
Рисунок 1 – Задачи ERP–систем
12. 2. Классические схемы разработки корпоративных систем
В процессе разработки любых проектов всегда участвуют такие компоненты как целеопределение, системотехника, технологии ресурсы и окружающая инфраструктура. Успешность реализации проектов всегда зависит от того, на сколько управляемы все эти компоненты. Создание и реализация проектов всегда предусматривает организацию работ в несколько фаз, т.к. в противном случае резко снижается управляемость работ. Ранее, при разработке проектов использовалась так называемая водопадная модель организации работ (рисунок 2).
Рисунок 2 – Водопадная модель
При такой модели работ все фазы выполнялись последовательно, а критериями качества, на основе которых строилась организация управления проектом – были полнота и законченность проектной документации на каждой стадии и планируемость сроков и стоимости работ. Управление качеством по этим критериям было возможно потому, что следующая фаза работ не могла начаться до завершения предыдущей. Применение «водопадной модели» является наиболее оптимальной, когда осуществляются проекты не требующие больших затрат времени и ресурсов.
При разработке и внедрении «больших» систем, например, систем управления предприятиями, такая схема приводила к тому, что сроки выполнения работ всегда сдвигались из-за того, что не учитывалась динамика изменений требований к разрабатываемой системе, а к моменту окончания разработки продукт формально отвечающий всем требованиям по качеству оказывался бесполезным или по крайней мере устаревшим. Одной из главных причин, по которой нарушались планы создания систем была «величина» системы. В современных условиях требования к разработке систем резко ужесточились. Сроки создания и внедрения таких систем должны быть резко сокращены, а сама система управления должна давать приращение нового качества в каждой функции управления, т. е. старый принцип работы таких систем – «Что на входе, то и на выходе» уже не удовлетворяет потребителя.
13. 3. Адаптивная организация проектных работ
Чтобы сократить сроки создания систем, затрачиваемые ресурсы и поддерживать систему на необходимом уровне «новизны» были разработаны новые подходы к организации проектных работ. Суть этих подходов заключается в том, чтобы вести разработку системы как бы по «спирали», создавая при прохождении нового витка очередной функциональный модуль системы.
Чтобы сократить сроки создания систем, затрачиваемые ресурсы и поддерживать систему на необходимом уровне «новизны» были разработаны новые подходы к организации проектных работ. Суть этих подходов заключается в том, чтобы вести разработку системы как бы по «спирали», создавая при прохождении нового витка очередной функциональный модуль системы.
Схема такой организации приведена на рисунке 3.
Рисунок 3 – Усовершенствованная организация разработки
Для этого на начальном этапе определяются архитектура и функциональность системы, определяются наиболее функционально значимые для Заказчика модули и последовательность их разработки. Таким образом, Заказчик получал необходимую ему систему по частям. В рамках разработки функционального модуля системы возможно организовать разработку по «водопадной схеме».
Сроки создания всей системы сокращаются не значительно, однако, Заказчик получает в довольно короткий срок рабочие, функционально законченные модули. Основные проблемы, которые возникают при такой схеме работ – это низкая управляемость всем процессом и согласование модулей системы.
Более совершенные формы организации работ заключаются в процессном подходе.
При процессной организации используется другой подход к объекту проектирования и процессу проектирования. На начальном этапе (концептуальный проект) определяются укрупненные функции системы, а затем они детализируются по ходу выполнения проекта, а также определяется базовая конфигурация проекта и строится сеть процессов проекта.
Работы проекта не имеют однозначного разделения по фазам и могут выполняться параллельно, при этом некоторые работы имеют сквозной характер, т.е. выполняются сразу в нескольких фазах. Из-за этого границы фаз становятся расплывчатыми. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей, однако сохраняется логика связей по исходным сведениям и задачам.
Схема такой организации работ представлена на рисунке 4.
Рисунок 4 – Процессная организация работ
Динамичность организации жизненного цикла по такой схеме позволяет значительно сократить время и в наибольшей степени удовлетворять требованиям потребителя.
Набор работ в рамках процесса приведен в таблице 1.
Таблица 1 – Набор работ
| Процесс | Работы |
| Разработка | Подготовка к реализации процесса Анализ требований к системе Архитектурное проектирование системы Детальное проектирование системы Квалификационные испытания Другие работы |
| Управление | Подготовка к реализации процесса Идентификация конфигурации Контроль конфигурации Планирование Выполнение и контроль Анализ и оценка |
| Заказ | Подготовка тендера Подготовка и корректировка контракта Текущий контроль поставщика Приемка и завершение работы |
Дата публикования: 2015-10-09; Прочитано: 725 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!
