Место информационных технологий в стратегии предприятия. Соотношение понятий ИТ, ИС, ИМ. Понятие информационного менеджмента. Управленческая структура объекта

Содержание: Лекция 1. Место информационных технологий в стратегии предприятия. Соотношение понятий ИТ, ИС, ИМ. Понятие информационного менеджмента. Управленческая структура объекта. 2 Лекция 2.Организация управления проектированием ИС. 11 Лекция 3. Стратегическое планирование развития ИТ и ИС на объекте управления. Типы ИС, тенденции их развития 19 Лекция 4.Выбор управленческой информационной системы. Классификация систем автоматизации управления предприятием. Минимальный перечень требований к системе, претендующей на “звание” корпоративной информационной системы. Выбор системы. Основные факторы успеха. Типичные ошибки. 25 Лекция 5. Принятие решений о приобретении ИТ – продукта. Проведение конкурса. Использование консалтинга. Оценка предложений поставщиков. 35 Лекция 6. Организация и реорганизация бизнес-процессов как подготовительный этап внедрения управленческой информационной системы. Понятие бизнес-процесса. Инструментарий и методология описания бизнес-процессов 66 Лекция 7.Организация внедрения ИС 75 Лекция 8. Разработка стратегии развития предприятия. Построение организационной структуры управления предприятием. 82 Лекция 9 Построение организационно-функциональной модели предприятия 88 Литература: 98 Лекция 1.Место информационных технологий в стратегии предприятия. Соотношение понятий ИТ, ИС, ИМ. Понятие информационного менеджмента. Управленческая структура объекта. 1.1. Место информационных технологий в стратегии предприятия Логика развития экономических процессов в промышленности, ограниченность финансовых средств, отсутствие инвестиций ставят труднейшие задачи перед предприятиями. Резкие колебания конъюнктуры спроса на рынке при жесткой конкуренции напрямую влияют на принятие управленческих решений. Для уменьшения степени риска при принятии решений необходимо иметь оперативную информацию о состоянии материальных, денежных и людских ресурсов на текущий момент, об узких местах, куда нужно направлять средства. В условиях многономенклатурного и наукоемкого производства все эти проблемы невозможно решить без эффективной организации сбора и обработки информации. В свою очередь, высокоэффективное управление на основе достоверной информации должно привести к улучшению ряда основных технико-экономических показателей деятельности предприятия: • к повышению комплектности производственных заделов и запасов; • к снижению объемов незавершенного производства; • к снижению себестоимости выпускаемой продукции и осуществляемых услуг; • к сокращению производственного цикла изготовления изделий и, следовательно, к уменьшению необходимого объема оборотных средств. С середины 80-х годов огромное внимание уделяется возможностям получения стратегических и конкурентных преимуществ путем использования ИТ в качестве элемента для данной стратегии. Стратегия ИС определяет потребности бизнеса и его отдельных функций в информационных системах. Дело руководителя – видеть компанию не такой, какая она есть, а такой, какой она может быть. (Джон У. Титс – директор – распорядитель компании Greyyjund). Стратегия организации – это управленческий план, направленный на укрепление позиций организации, удовлетворение потребностей ее клиентов и достижение определенных результатов ее деятельности. Разработка стратегии – это основные управленческие функции. Если организация хочет, чтобы ее управление оценивалось как отличное, она должна продемонстрировать отличную реализацию отличной стратегии. Стратегия ИС должна определять, какие ИС необходимы для бизнеса в обозримом будущем, базируясь на анализе бизнеса, его среды и основной бизнес – стратегии. Стратегия ИТ определяет, как будут достигнуты цели, основываясь на приоритетах ИС - стратегии и информационной технологии необходимой для для развития и использования существующих и будущих операций. 1.2. Соотношение понятий ИТ, ИС, ИМ. Понятие информационного менеджмента. Информационное взаимодействие производственных процессов и процессов управления можно представить следующим образом. Рис.1 .2.1. Информационное взаимодействие процесса управления и производственного процесса. В таком соотношении производственный процесс можно интерпретировать как среду, порождающую информацию, а процесс управления - как среду, использующую информацию. Отметим, что в основе процесса управления лежит множество информационных процессов, которые включают в себя информационное отображение производственного процесса, преобразование, хранение, передачу информации, выработку управленческих воздействий на производственный процесс (управленческих решений) и подчиняются некоторому комплексу закономерностей, определяемых понятием «информационное пространство». Проводя аналогию между производственной системой и ИС можно сказать, что продукцией последней является информация. Причем эта продукция может быть измерена количественно, имеет свое качество и стоимость. В то же время процесс управления является не чем иным, как процессом взаимодействия работника системы управления с информацией. При этом процесс управления представляет собой комплекс процессов по созданию, хранению и переработке данных с целью получения информации как продукта данного процесса для использования ее в процессе принятия решения. Основой любого производства является технология. В случае ИС – это информационная технология (ИТ) или технология преобразования информации (сбор, передача, хранение, отображение и обработка), реализуемая с помощью специального оборудования и программного обеспечения (рис.1.1.5). Рис.1.2.2.Структура элементарного процесса обработки информации. Стремительное вхождение предприятий в рыночные условия потребовало от них мобильности и оперативности при принятии решений. Задержка необходимой информации или ее недостоверность могут поставить предприятие на грань краха. Особенно это касается информации о финансах. В этих условиях информационные системы начинают играть ведущую роль на предприятии и вносить существенный вклад в процесс принятия решений. На создание, внедрение и эксплуатацию информационных систем тратятся огромные материальные, временные и трудовые ресурсы, которые в дальнейшем будут только возрастать. Ясно, что эффективность этих затрат в основном определяет темп научно – технического прогресса. С другой стороны, управление эффективностью таких затрат – есть задача общего менеджмента, аналогично, управление эффективностью затрат в ИС – есть задача информационного менеджмента (ИМ). Тогда основной задачей, решаемой ИМ, является обеспечение эффективности создания, внедрения и эксплуатации ИС, реализующей ИТ. Использование методов и приемов ИМ на предприятии позволяет повысить эффективность существующих ИС, избежать неоправданных затрат и повысить конкурентоспособность. Вопросы и задачи, решаемые ИМ, можно проиллюстрировать на основе обобщенного комплекса технических и программных средств информатизации и их методологического обеспечения. • Количество компьютеров и их периферии, установленных в информационных системах огромно, а их мировое производство представляет собой мощную отрасль индустрии, исключительно наукоемкую и динамичную. Сюда же относятся разного рода сервисные услуги. Эта индустрия стала транснациональной. Ее продукты сформировали мировой рынок средств и услуг информатизации. Ориентироваться на рынке комплекса технических средств и услуг и оперативно реагировать на все его изменения – задача ИМ. • Многие сферы деятельности предприятий стали широко интегрированными и требуют кооперации ИС, и, следовательно, решения задач ИМ. • Разработка и эксплуатация ИС предприятий также требует решения задач ИМ. Ресурсы системы ограничены, а количество решаемых задач возрастает, следовательно, необходимо обеспечивать непрерывное повышение эффективности ИС и адекватности решаемых задач. • Мощным фактором развития ИС является конкуренция, которая требует самой оперативной и полной информации, дающей конкурентные преимущества перед соперником. Позтому, пренебрежение развитием совершенствованием ИС часто ведет к поражению фирмы. Решение проблем обеспечения оперативной и полной информацией, дающей конкурентные преимущества перед соперником, – задача ИМ. • Объем информации непрерывно возрастает (удвоение объема информации в мире происходит в течение 2,5 – 3 лет), ее внутренние связи усложняются, затрудняется ее поиск и эффективное использование. Эффективное использование все возрастающего потока информации - это тоже задача ИМ. ИМ можно представить как триаду: информация (основной предмет труда и продукт), информационная технология (последовательность действий во времени по преобразованию информации), информационная система (совокупность специальных средств преобразования информации и сфера деятельности менеджмента), - все это имеет существенную специфику, отличающую ИМ от менеджмента в других сферах. ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ ▪ Информация ▪ Информационная технология ▪ Информационная система 1.3. Структура объекта и процесса управления. "Всякий непосредственно общественный труд нуждается в управлении". Эта аксиома, высказанная К. Марксом в "Капитале", определяет две взаимосвязанные составляющие общественного производства. Учитывая, что под термином "общественный труд" понимается прежде всего процесс производства, можно интерпретировать данное определение следующим образом (рис.1.3.1): Рис. 1.3.1. Взаимосвязь систем управления и производства Понятие "Управление" и понятие "Производство" с системной точки зрения представляют собой отражение некоей системы, состоящей из двух самостоятельных подсистем (систем): система управления и производственная система, - находящихся в тесном взаимодействии и единстве. В то же время каждая из этих систем имеет свою внутреннюю структуру. Например, производственную систему можно структурировать следующим образом (рис. 1.3.2). Таким образом, понятие "производственный процесс" можно сформулировать, как взаимодействие средства труда, предмета труда и труда (рабочей силы) с целью получения продукта. При этом средство труда, предмет труда и труд представляют собой ресурсы, которые в процессе взаимодействия овеществляются в продукте. Рис. 1.3.2. Структура производственной системы. Где: ПТ - предмет труда; СТ - средства труда; Т - труд; П - продукт (результат труда) Взаимодействие системы управления и производственной системы осуществляется в процессе передачи каких-либо управляющих воздействий и получении обратной связи посредством информации, т.е. осуществляется информационное взаимодействие двух систем. А это, в свою очередь, определяет основное содержание системы управления (СУ) как системы порождающей и потребляющей в том или ином виде информацию о процессе производства и, естественно, содержащей в своей основе процессы преобразования информации. Информация в этом случае становится для процесса управления как продуктом, так и предметом труда (рис. 1.3.3). Рис. 1.3.3. Структура системы управления. Где: ПТ - предмет труда; П- продукт; СТ - средства труда; Т – труд. Элементы системы управления (рис. 2.1.3) можно интерпретировать следующим образом: • ПТинф - предмет труда, т.е. информация, которая подвергается определенным воздействиям и преобразованиям в процессе управления. • Пинф - продукт, т.е. информация, направляемая непосредственно в процесс производства и определяющая параметры взаимодействия элементов производственной системы. • СТ - средства труда, т.е. оборудование, носители информации, программное обеспечение и т.п., применяемые в процессе преобразования информации. • Т - работники системы управления, занятые в процессе воздействия на процесс преобразования информации. Принципиальные основы декомпозиции производственного процесса требуют дальнейшей конкретизации на основе более глубокого исследования особенностей производственного процесса машиностроительного предприятия. Матрица производственного процесса, представленная на рис. 2.2.1., по сути содержит совокупность элементарных производственных процессов, выступающих в качестве элементарных объектов управления. Понимая производственный процесс как совокупность процессов обеспечения и использования ресурсов, мы должны проанализировать всю совокупность ресурсов, участвующих в производственном процессе, и всю совокупность операций (элементарных процессов) по обеспечению и использованию этих ресурсов. Представленная в таком виде структура производственной системы будет очень громоздкой и непригодной для дальнейшего исследования. Так как формирование этой структуры мы проводим с целью анализа процесса управления, то ее можно укрупнить, объединив однородные с точки зрения управления элементарные производственные процессы. Укрупнение структуры производственной системы надо вести с одной стороны по вертикали, объединяя однородные ресурсы, а с другой стороны по горизонтали, объединяя однородные операции. В основу укрупнения по вертикали целесообразно взять классификацию ресурсов, используемую в системах бухгалтерского учета и отчетности, в основе которой лежат статьи актива баланса предприятия. Не меняя содержания статей баланса проведем корректировки наименований отдельных статей с целью конкретизации их восприятия в связи с проводимым исследованием и представим их как перечень ресурсов, обеспечивающих функционирование производственного процесса (рис.1.3.4.). № Наименование ресурса Граф структуры 1 Нематериальные ресурсы (патенты, лицензии, товарные знаки и др.) 2 Земельные участки и объекты 3 Здания, сооружения (включая незавершенное строительство) 4 Машины, оборудование, производственный и хозяйственный инвентарь 5 Сырье и материалы, полуфабрикаты, комплектующие, топливо 6 Инструменты 7 Продукция предприятия 8 Энергетические ресурсы 9 Ресурсы сельскохозяйственного производства 10 Трудовые ресурсы 11 Финансовые ресурсы Рис.1.3.4. Перечень ресурсов производственной системы предприятия. Группировку операций процессов обеспечения на однородные группы по горизонтали удобно произвести по принципу единства потребляемых ресурсов, используемых в непрерывном интервале операций (обеспечиваемый ресурс в данном случае является предметом труда). На основании анализа реальных производственных процессов можно выделить следующие обобщенные группы операций обеспечения ресурсами, характерные для всех групп ресурсов: • получение со стороны; • создание на предприятии; • транспортировка; • хранение; • восстановление (ремонт); • совершенствование (модернизация); • использование; • выбытие. Обобщенная структура производственной системы как совокупность отдельных производственных процессов представлена на рис.2.2.3. При этом исключены отдельные элементы, не характерные для типичного машиностроительного предприятия. Учитывая то, что данная матрица охватывает весь перечень ресурсов предприятия и все процессы от появления ресурса на предприятии до его выбытия, можно определить ее как модель жизненного цикла ресурсов предприятия. Рассмотренный выше способ анализа объекта управления с учетом дальнейшего исследования его элементов до уровня элементарных операций можно назвать методом элементной структуризации. Данный метод позволил обосновать и провести декомпозицию производственного процесса предприятия до уровня однородных управляемых (производственных) процессов, сохраняя при этом полноту и целостность производственного процесса предприятия. Сформированная таким образом структура производственного процесса предприятия представляет собой базис для анализа и построения процессов управления и обеспечивает объектную составляющую в процессах системного моделирования. Эту схему преобразования информации можно считать последовательностью этапов процесса управления и применить к организационным системам, используя соответствующую терминологию (рис. 1.3.5). Рис. 1.3.5. Последовательность этапов процесса управления. Приведенную на рис. 1.3.5 терминологию можно предварительно характеризовать следующим образом: • НОРМИРОВАНИЕ - задание исходных значений параметров для процесса планирования; • ПЛАНИРОВАНИЕ - задание параметров функционирования управляемого процесса, обеспечивающих реализацию целей; • УЧЕТ - формирование информации о состоянии управляемого процесса. • АНАЛИЗ - сравнение заданных параметров функционирования объекта с учетными. • РЕГУЛИРОВАНИЕ - выработка параметров воздействия на управляемый процесс Таким образом, нормирование, планирование, учет, анализ и регулирование можно считать этапами или общими функциями управления. Более полно с учетом положений, изложенных в [226, 255], применительно к организационным системам содержание этих функций можно сформулировать следующим образом: Нормирование - функция процесса управления, заключающаяся в установлении технических, экономических и организационных ограничений (норм и нормативов) функционирования производственного процесса. Сюда входят конструкторская, технологическая и организационная подготовка производства (разработка конструкции, технологических маршрутов, норм времени и расхода материалов, размеров партий, страховых запасов, производственной структуры и др.) Надо отметить, что функция «нормирование» с точки зрения рассматриваемого контура управления (рис.1.3.5.) и содержания представляет собой статическую модель производственного процесса и предоставляет входящие данные для рассматриваемых в настоящей работе процессов управления. Планирование - основная функция управления, осуществляющая разработку заданий на определенный промежуток времени и организационное оформление этих заданий в качестве показателей деятельности, по которым осуществляется ее контроль и оценка. Учет - функция процесса управления, заключающаяся в наблюдении за фактами и явлениями производства, их измерении, регистрации, группировке и преобразовании к виду, удобному для анализа. Анализ - функция процесса управления, заключающаяся в сравнении плановых и учетных параметров и представлении информации для выработки управляющего воздействия. Регулирование - функция процесса управления, заключающаяся в выработке на основании аналитической информации управленческих решений, направленных на корректировку параметров функционирования управляемого процесса. Как уже отмечалось выше, процесс управления отражает в своей структуре управляемый (производственный) процесс. Другими словами, каждому элементу производственного процесса - элементарному производственному процессу - соответствует элементарный управленческий процесс, характеризующийся последовательностью общих функций управления. Наложение последовательности общих функций управления на матрицу производственной системы дает трехмерную матрицу функций процесса управления предприятием (рис.1.3.6). Рис. 1.3.6. Матрица функций процесса управления предприятием Так как при формировании матрицы производственной системы обеспечивается определенная внутренняя однородность каждой ячейки, то можно сказать, что каждой ячейке матрицы процесса управления присуща такая же однородность. Каждую такую ячейку можно считать конкретной (в отличие от общих) функцией управления, а в целом такую матрицу можно назвать функциональной структурой системы управления предприятием. Полная матрица функциональной структуры будет иметь аналогичный вид с перечнем ресурсов, развернутым до необходимого уровня дифференциации. Методы практического использования такой матрицы зависят от целей конкретного исследования и предполагают дифференцированный подход в каждом отдельном случае. Например, целью функционально-содержательного анализа может быть упорядочение распределения управленческих функций на предприятии, выявление незакрепленных функций, функций, которые не свойственны тем или иным подразделениям, случаев дублирования функций и др. Такой анализ осуществляется посредством определения на основе предложенной матрицы эталонного состава функций, сравнения его с фактически выполняемым и включает в себя: • обследование и фиксирование состава функций управления, которые имеют место на предприятии; • сравнение этого состава с эталонным и выявление незакрепленных функций или случаев их дублирования; • разработку моделей рассматриваемых процессов. При обследовании основной задачей является выявление и анализ всего состава функций, выполняемых на предприятии тем или иным производственным подразделением или работником методом изучения положений и должностных инструкций, а также с помощью устного опроса экспертов, и сравнение его с эталонным составом функций. Эталонный или стандартный перечень функций формируется на основе матрицы. Необходимо отметить, что перечень ресурсов дополнен информационным ресурсом, являющимся предметом труда в системе управления. Таким образом, исследование функциональной составляющей процесса управления с использованием метода имитационного моделирования процессов автоматического регулирования позволило обосновать известный состав и содержание общих функций контура управления (нормирование, планирование, учет, анализ, регулирование) и сформулировать содержание конкретных функций как проявление общих функций в каждом конкретном контуре управления элементарным производственным процессом. Соответственно, наложение последовательности общих функций управления на матрицу производственного процесса позволило графически представить полную структуру функций управления предприятием и сформировать эталонный или стандартный перечень функций управления, который составляет основу дальнейшего анализа и формирования моделей системного проекта. Лекция 2.Организация управления проектированием ИС. Управленческая роль ИТ - менеджмента на различных этапах жизненного цикла информационного продукта. Структура ИТ – подразделений на предприятиях различных типов. Место ИТ – подразделения в организационной структуре предприятия. Планирование деятельности ИТ – подразделения. 2.2. Организационные формы управления проектированием ИС 2.3/Структура организации работ по проектированию ИС, характерная для организации – разработчика. 2.4. Структурные схемы для информационной службы предприятия . 2.5. Планирование и контроль проектных работ. 2.1.Управленческая роль ИТ – менеджмента на различных этапах жизненного цикла информационного продукта Организация процессов разработки проекта ИС отличается значительной сложностью. К причинам, обусловливающим сложность данных процессов, следует отнести прежде всего: • масштабы разработки ЭИС; • взаимосвязь различных по своей природе элементов проекта ЭИС (информационные, программные и технические средства обработки информации; экономико – математические модели; методы и средства проектирования; специалисты – разработчики; элементы проекта системы и др.); • различные факторы старения указанных элементов; • разный временной цикл существования и темпов обновления элементов; • длительность процесса проектирования системы; • индивидуальность проекта, обусловленную спецификой объекта проектирования; • коллективный характер труда многих специалистов различной квалификации. Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, в денежных средствах и материальных ресурсах, а также по качеству конечных результатов проекта (документированных, например, в техническом задании). Управление как процесс характеризуется следующими компонентами: целью управления, ограничениями, объектом и субъектом управления, контуром управления, методами и средствами управления. Управление проектированием, как правило, рассматривают в двух аспектах: функциональном и организационном. Функциональный аспект определяется последовательностью работ по созданию проекта. Методология создания ИС отражена в нормативных документах, подавляющее большинство которых имеет силу международных стандартов. В них определены терминология, порядок создания и внедрения, требования к частям, состав проектов. Последовательность работ, связанных с определением целесообразности создания, созданием и промышленной эксплуатацией информационных систем (ИС), оформлена в виде процесса (создания или изготовления), который имеет иерархическое описание и состоит из стадий. Каждая стадия состоит из этапов, а этапы, в свою очередь, из видов работ. ИМ реализует функции управления на протяжении всего жизненного цикла ИС, который включает фазы “зарождение”, “создание и внедрение”, “эксплуатация”, “демонтаж”. Важнейшей фазой жизненного цикла ИС является фаза “создание и внедрение”, которая состоит из шести стадий: технико – экономическое обоснование (ТЭО), техническое задание (ТЗ), технический (ТП) и рабочий (РП) проекты, внедрение (Вн), анализ функционирования. Процесс создания и внедрения включает следующие стадии, этапы и некоторые виды работ. СТАДИЯ 1. Технико – экономическое обоснование (ТЭО). Основная цель работ этой стадии состоит в формировании обоснованного с позиций заказчика системы предложения о создании ИС с определенными основными функциями и техническими характеристиками. Основными выходными документами на этой стадии являются: ТЭО создания ИС и исходные технические требования к ИС в объеме, соответствующем ГОСТ. СТАДИЯ 2. Техническое задание (ТЗ). Основными целями стадии являются: подтверждение целесообразности и детальное обследование возможности создания эффективной ИС с функциями и техническими характеристиками, сформулированными в виде исходных технических требований к системе, планирование совокупности всех НИР, ОКР, проектных и монтажно – наладочных работ, сроков их выполнения и организаций исполнителей, подготовка всех материалов, необходимых для выполнения проектных работ. Выходными документами стадии являются: ТЗ на создание ИС, содержащее технические требования и план – график работ, согласованные Заказчиком и основным исполнителем; уточненное технико- экономическое обоснование намеченных в ТЗ решений (при необходимости); научно – технический отчет, содержащий результаты проведенных предпроектных исследований; эскизный проект ИС. СТАДИЯ 3. Технический проект (ТП). Целями работ, выполняемых на этой стадии, являются разработка основных технических решений по создаваемой системе и окончательное определение ее сметной стоимости. Работы этой стадии завершаются разработкой: общесистемных решений, необходимых и достаточных для выпуска эксплуатационной документации на систему в целом, входящей в состав раздела “Автоматизация” технического проекта строительства; проектов заявок на разработку новых технических средств; документации специального математического и информационного обеспечения, включая техническое задание на программирование. Основные результаты работ стадии оформляются в виде технического проекта ИС. СТАДИЯ 4. Рабочий проект (РП). Целью работ, выполняемых на этой стадии, является выпуск рабочей документации на создаваемую систему. Работы на этой стадии завершаются выпуском рабочего проекта ИС, состоящего из проектной документации, необходимой и достаточной для приобретения, монтажа и наладки комплекса технических средств системы и документации и программного организационного обеспечений, необходимых и достаточных для наладки и эксплуатации системы, и изготовлением программ специального программного обеспечения на машинных носителях СТАДИЯ 5. Внедрение (Вн). Цель стадии и главный результат работ, выполняемых здесь – передача действующей системы в промышленную эксплуатацию. СТАДИЯ 6. Анализ функционирования (АФ). Цель работ, выполняемых на этой стадии, состоит в получении систематизированных и объективных данных о ткачестве создаваемой системы, текущем состоянии и реальном эффекте функционирования системы на основании опыта ее промышленной эксплуатации. Анализ функционирования выполняется в ходе промышленной эксплуатации и не ранее, чем через 0,5 года со дня сдачи в промышленную эксплуатацию. С этой целью определяются показатели эксплуатационной надежности для системы в целом и для отдельных реализуемых ею функций, показатели технико – экономической эффективности системы, функционально – алгоритмическая полнота (развитость) системы и социально – психологическая подготовка персонала системы. Здесь же выносится решение о возможности дальнейшей эксплуатации системы, ее модернизации и дальнейшем развитии. 2.2. Организационные формы управления проектированием ИС В общем случае организационная структура управления проектированием регулирует взаимоотношения подразделений и должностных лиц в организации, устанавливает распределение ролей, полномочий и ответственности между ними, а также порядок функционально-технических связей, возникающих в процессах управления. 2.2.1.Организационная структура и организационный механизм как система связи в данной организации образуют организационные формы управления деятельностью коллектива. Можно передать в распоряжение разработчиков самые совершенные средства проектирования, четкие формы документации, планы работ, методы контроля, но без должной организации не получить проект, удовлетворяющий потребностям заказчика. И наоборот, совершенная форма организации проектирования может компенсировать недостаток эффективных средств проектирования и в отдельных случаях даже квалификацию разработчиков. - Функциональный принцип построения структуры организации используется при выполнении задач проектирования постоянного характера. Для выполнения каждого вида задач, например, разработки постановки экономических задач, информационного обеспечения и т.п., формируются функциональные подразделения из специалистов определенного профиля. Подобная организационная структура обладает высокой степенью централизации управления, ей присущ авторитарный стиль руководства. В области разработки ИС функциональная структура организации встречается весьма редко. - Для построения организационных структур проектных организаций наиболее часто используется проектный принцип. На основе этого принципа формируется организационное подразделение - проектная группа (проект), которая предназначена для одноразовой разработки ИС. Специалисты проектной группы образуют автономную организационную единицу, руководитель (главный конструктор) которой имеет соответствующие полномочия и несет полную ответственность за результаты деятельности проектного коллектива, который после выполнения проекта может быть расформирован. - Матричный принцип построения организационных структур предполагает формирование в организации – разработчике ЭИС из специалистов функциональных подразделений проектных групп для разработки конкретных проектов. При этом специалисты не теряют принадлежности к соответствующему функциональному подразделению и находятся в двойном подчинении: у руководителя проекта (ответственность по проекту) и у руководителя функционального подразделения (организационная ответственность). Матричные структуры применяются в условиях высокой степени кооперации функциональных подразделений. Эти структуры основаны на особом механизме взаимодействия функциональных и проектно-целевых подсистем аппарата управления проектной организации. Главная особенность матричных структур состоит в обязательном выделении конкретного лица – руководителя проекта, наделенного всей полнотой ответственности за достижение цели проектирования и значительными правами распорядительства, которые делегируют ему вышестоящим руководством. 2.2.2.Выбор целесообразного разделения труда разработчиков ИС зависит от ряда факторов, влияющих с разной степенью на решение проблемы. Наиболее существенными факторами являются следующие: • потенциал коллектива разработчиков; • объем и сложность разрабатываемых проектов; • технология проектирования системы; • модель жизненного цикла системы. Открытая организационная структура отличается тем, что закрепленного организационного распределения обязанностей нет. Каждый член коллектива разработчиков является неформальным руководителем на этапе разработки системы, где он более других квалифицирован. Обязанности на отдельных этапах распределяются между разработчиками в соответствии с их знаниями, опытом и способностями. Централизованная организационная структура проектной группы предусматривает в качестве руководителя специалиста высокой квалификации, осуществляющего административное и техническое руководство. Он же является основным посредником между группой, заказчиком проекта и внешними организациями. Децентрализованная организационная структура проектной группы имеет свойство двух вышеизложенных структур. Данная организационная структура применяется в коллективах с большой численностью разработчиков (свыше 10 человек), осуществляющих проектирование больших ЭИС, декомпозируемых на подсистемы (контуры, модули) и комплексы задач. 2.3Структура организации работ по проектированию ИС, характерная для организации - разработчика В организационном аспекте управление проектированием рассматриваются по уровням организационно-административной структуры с соответствующими правами и обязанностями субъектов процесса проектирования. Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком. Пользователь – это организация или группа подразделений, которые используют результаты обработки информации на ЭВМ. Для ИС под пользователем понимают прежде всего административно-управленческий аппарат, для которого создается эта система. Пользователь выполняет следующие функции: -формирует исходные данные для проектирования и обработки; -определяет состав задач для автоматизации; -определяет основные требования к задачам и режим функционирования системы. Заказчик – это ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции: -формирует требования к системе и ее частям; -выдает техническое задание, финансирует разработку ЭИС; -обеспечивает проведение комплекса мероприятий по ее созданию; -проводит внедрение и прием проекта ЭИС. При этом заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ЭИС исходным данным пользователя, за сроки создания системы, правильность использования ресурсов в процессе проектирования. Администратор – ответственное лицо, которое выполняет эксплуатацию программно-технических средств и информационного и методологического обеспечения ЭИС (технологические и инструкционные карты ). Администратор несет ответственность перед пользователем за правильность результатов работы ЭИС и их своевременность, а перед заказчиком и разработчиком – за соблюдением условий эксплуатации, требований к технической документации. Разработчик – это ответственное лицо (организация или подразделение), которое выполняет следующие функции: -разрабатывает ЭИС по техническому заданию заказчика; -принимает участие во внедрении; -осуществляет сдачу проекта заказчику; осуществляет авторское сопровождение проекта. Разработчик несет ответственность перед заказчиком за правильность реализации требований ТЗ на ЭИС, научно-технический уровень разработки, сроки проведения работ, качество проектной документации, правильность расхода денежных ресурсов. Под разработчиком понимается как одна организация, так и некоторая совокупность организаций, в которую входят головная организация и организации-соисполнители. Существует несколько типов схем организации работ с участием сторон, выбор которых зависит от объема заказа. 1. Если заказ имеет небольшие размеры по стоимости и по продолжительности работ, то принимают первую схему, в которой в одном лице выступают заказчик, разработчик и администратор. К преимуществу данной схемы можно отнести минимальное количество организаций – участников процесса и минимальные сроки и стоимость разработки. Однако совмещение в одной организации функций разрабатывающей стороны и принимающей стороны имеет ряд существенных недостатков: -отсутствует действенный контроль за научно-техническим уровнем разработки, сроками выполнения работ; -не достигается высокого профессионального уровня разработчиков. 1. Для больших и сложных заказов применяют схему, согласно которой функции разработчика отделяются от функций заказчика и администратора и выполняются другой организацией. К преимуществам данной схемы можно отнести: -рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС; -возможность привлечения к разработке ЭИС специализированных организации ( НИИ, СКБ ). Однако и эта схема имеет недостатки: -отсутствие прямой связи между разработчиком и пользователем, что создает трудности в своевременном получении и детализации исходных данных для проектирования; -определенные трудности при приеме проекта в эксплуатацию из-за желания администраторов получить методологическое обеспечение задач, максимально соответствующие идеальным условиям эксплуатации, что в свою очередь, требует больших сроков и объемов по доработке проекта. 2. В том случае, если заказчик – большая организация, которая курирует разработку нескольких проектов ЭИС, применяют схему организации работ при полном разделении работ участвующих сторон. Данная схема характеризуется тем, что на заказчика возлагаются функции сопровождения, заказа и приемки проектов нескольких ЭИС. Преимуществами данной схемы являются: -более высокая степень специализации работников, следовательно, более высокий профессиональный уровень; -возможность организации контроля за сроками и качеством выполнения работ. 3. Отделение заказчика от разработчика позволяет последнему привлекать к своей работе организации-соисполнителей разных уровней иерархии, что в свою очередь, позволяет использовать труд специализированных и профессиональных организаций. Схема организации работ с использованием организаций – соисполнителей. Основными документами, регулирующими отношения заказчика и проектировщика, являются техническое задание и договор на проведение работ. 2.4. Структурные схемы для информационной службы предприятия Существуют три вектора, по которым целесообразно выстраивать первый уровень в организационной иерархии: 1. функции, 1. клиенты, 2. продукты. 2.4.1.Организация по функциям Разбиение по функциям применяется чаще всего, особенно в информационных службах. Например, Управление состоит из подразделений: • отдел анализа и документирования технологий, • отдел прикладных систем, • отдел телекоммуникаций, • отдел системотехники и базового ПО. Привлекательность такого подхода состоит в следующем. -Обеспечивается специализация. Каждый отдел выполняет ограниченный набор функций, что стимулирует эффективный обмен знаниями. • Практически не возникает дублирования, создаются условия для стандартизации как внутри информационной службы, так и снаружи. • Легче достигается эффективный масштаб, что особенно актуально для тяжеловесных решений на базе мэйнфреймов, и в меньшей степени, но все же важно, для клиент - серверных систем. Под эффективным масштабом подразумевается такой размер подразделений, при котором выполнение капиталоемких функций становится экономически целесообразным. Например, пять небольших подразделений, разрабатывая ПО в рамках своих скромных бюджетов, будут использовать дешевый Microsoft Access. Объединенное подразделение, располагающее объединенным бюджетом, может позволить себе использовать дорогой Oracle. • Руководитель Управления облегчает себе принятие решения об исполнителях по каждой новой задаче. Недостатки функционального подхода также хорошо известны: -Возникают проблемы с комплексным обслуживанием клиентов (внешних подразделений), предоставлением разных услуг разным клиентам. -Страдают скорость и качество оказываемых услуг. -Воздвигаются « местнические» барьеры между отделами, что негативно сказывается на готовности проводить изменения в соответствии с изменениями внешней среды. Недостатки функционального подхода частично нивелируются применением клиентской или продуктивной схемы. 2.4.2.Организация по клиентам Организационная структура Управления в разрезе по клиентам могла бы выглядеть, например, таким образом: -отдел производственных систем, -отдел сбытовых и маркетинговых систем, -отдел систем учета и отчетности, -отдел делопроизводства и систем управления кадрами. Клиентская схема организации обеспечивает: -Более качественное и быстрое обслуживание за счет ориентации на конкретные категории клиентов и даже отдельных клиентов. -Более полное удовлетворение клиента за счет детального знания его потребностей и внутренних особенностей. Недостатками клиентской схемы являются: -Дублирование функций (тех, что указаны для отделов функциональной структуры), выполняемых отдельно для каждого клиентского сегмента. -Потеря экономии от масштаба. 2.4.3. Организация по продуктам Продуктами (результатами) деятельности информационной службы являются информационные системы, понимаемые как совокупность аппаратно-программных комплексов и услуг по сопровождению этих комплексов. Управление в разрезе по продуктам чисто условно могло бы выглядеть так: -отдел разработки и сопровождения системы X, -отдел разработки и сопровождения системы Y, -отдел разработки и сопровождения системы Z. В этом случае помимо плюсов, характерных для клиентской схемы, возникает еще один - сокращение времени на разработку новых продуктов (систем ). Среди дополнительных минусов - проблема комплексного обслуживания клиентов по набору продуктов. Дополнительно к перечисленным вариантам есть еще пара способов выстраивания первого уровня иерархии Управления: -по территориальному признаку, -по основным внутренним процессам. Первый из них является скорее следствием жесткой необходимости и исторических причин, чем результатом продуманного выбора. Второй способ представляет собой хорошую альтернативу для функционального варианта, имеет дополнительные преимущества, но требует особой подготовки и аккуратности. Наибольшая трудность при использовании данного способа - правильное определение основных процессов, что само по себе задача нетривиальная, особенно если ранее эта работа находилась не на должном уровне. Тем не менее, можно представить один из вариантов данного структурного решения, при котором информационная служба разделялась на две части: одна отвечала за развитие, другая – за сопровождение. И такой подход давал хорошие результаты. 2.5. Планирование и контроль проектных работ. Управление проектированием ИС в функциональном аспекте рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимаются действия и процедуры, связанные с решением конкретных задач или реализацией функций управления, к которым относятся: • процессы инициации, связанные с принятием решения о начале выполнения проекта или какого-либо очередного этапа или фазы его; • процессы планирования - совокупность процедур, связанных с определением целей и критериев успеха проекта и разработкой рабочих схем и достижения; • процессы исполнения, предназначенные для координации людей и других ресурсов для выполнения плана; • процессы анализа, дающие возможность определить соответствие плана и исполнения проекта поставленным целям и критериям успеха и принять решения о необходимости применения корректирующих воздействий; • процессы оперативного управления или регулирования - совокупность процедур, предназначенных для определения необходимых корректирующих воздействий, их согласования, утверждения и применения; • процессы завершения- процессы формализации выполнения проекта и составления отчетности. Лекция 3. Стратегическое планирование развития ИТ и ИС на объекте управления. Типы ИС, тенденции их развития 1.Управление процессом автоматизации. Формирование и развитие на предприятии информационной системы, предназначенной для обеспечения постановки и поддержки принятия решения производственных и управленческих задач в их стратегической перспективе, всегда требуют долгосрочного планирования, ориентированного на стратегические цели в области организации, развития и использования ИС, т.е. стратегического планирования ИС. Эти задачи и функции являются частью информационного менеджмента предприятия и требуют, в свою очередь, полной интеграции задач ИС в систему планирования предприятия в целом. Процесс автоматизации как и любой управляемый процесс предполагает наличие следующих функций управления: -планирование, -контроль исполнения плана, -регулирование – анализ результатов и принятие решений. 1.1.Планирование. Как правило, существуют два типа планов автоматизации предприятия: -стратегический план, -оперативный план. Крайне желательно, чтобы и стратегический, и оперативный планы были составлены в письменном виде. Отличие стратегического плана от оперативного состоит в следующем. Стратегический план за редким исключением не содержит плана конкретных работ. В нем фиксируются принципы и условия, с соблюдением которых должны осуществляться принятия решений на каком либо отрезке времени, и результаты, описанные в терминах бизнеса, которые должны быть достигнуты при соблюдении этих условий. Поэтому в некотором смысле он, с одной стороны, является планом принятия управленческих решений, а с другой – фиксирует условия, соблюдения которых необходимо при принятии решений. Стратегический план может не быть календарным, т.е. рассчитанным на год, три или пять лет, а носить условный характер, т.е. действовать до наступления некоторых условий, например образование новых подразделений, достижение объема продаж не ниже… и т.д. Результатом стратегического плана ИС должен являться документ, который содержит, во-первых, констатацию существующего положения в области ИС как на предприятии, так и вне его, во-вторых, разработанные по годам стратегии в этой области и необходимые для их реализации на предприятии мероприятия. Оперативный план, как правило, содержит план конкретных работ по реализации принятых стратегических решений, описанных в технических терминах. Он включает в себя события, которые должны произойти, носит календарный характер, т.е. привязан к календарным датам (год, полгода, квартал), и сопровождается сметой расходов или графиком инвестирования средств. 1.2.Контроль исполнения планов подразумевает наличие процедур периодического сбора информации, ее обобщение и представление оперативной информации лицам, принимающим решения в форме, принятой на предприятии. Например, отставание от календарных сроков, перерасход или, наоборот, недорасход средств, выделяемых на автоматизацию. В состав представляемой оперативной информации в обязательном порядке должна включаться информация о возникших по мере реализации плана проблемах. 1.3.Анализ результатов и принятие решений подразумевает наличие процедуры анализа результатов, опираясь на который производится ревизия плана или внесении изменений в ход процесса. Процедура может носить как периодический характер так и инициироваться при наступлении каких-либо событий: превышение бюджета, отставание от сроков. 2.Стратегический план. Стратегия автоматизации в первую очередь должна соответствовать приоритетам и стратегии (задачам) бизнеса предприятия. В понятие стратегии также должны входить пути достижения этого соответствия. Стратегический план автоматизации должен составляться с учетом следующих факторов: -средний период между сменой технологий основного производства; -среднее время жизни выпускаемых предприятием продуктов и их модификаций; -анонсированные долгосрочные планы поставщиков технических решений в плане их развития: снижение доли нестандартизованных компонентов на всех уровнях (интерфейсы, контроллеры, операционная система и т.д.), расширение типов совместимых платформ; создание средств конвертации данных, систем архивирования; интеграция со смежными системами; -срок амортизации используемых систем; -стратегический план развития предприятия, включая планы слияния и разделения, изменение численности и номенклатуры выпускаемой продукции; -планируемые изменения функций персонала. Таким образом, стратегия автоматизации представляет собой план, согласованный по срокам и целям со стратегией организации. Исходя из выше сказанного, мероприятия по сохранению инвестиций должны быть направлены на обеспечение требуемой рентабельности эксплуатации информационной системы и возможности ее развития с учетом произведенных затрат. Низкая отдача от использования информационной системы при высоких затратах на ее эксплуатацию, а также неспособность фирмы изменить это положение говорит о нецелесообразности сохранения этих инвестиций, т.е. систему лучше в дальнейшем не использовать. Понятие стратегии автоматизации включает в себя базовые принципы, используемые при автоматизации предприятия. В ее состав входят следующие компоненты: 2.1Цели бизнеса: -области деятельности предприятия и последовательность, в которой они будут автоматизированы; -степень соответствия приоритетов автоматизации и стратегии бизнеса, а именно – целям, которые должны быть достигнуты: • снижение стоимости продукции; • увеличение количества или ассортимента; • сокращение цикла: разработка новых товаров и услуг – выход на рынок; • переход от производства на склад к производству под конкретного заказчика с учетом индивидуальных требований и т.д. Стратегические цели бизнеса с учетом ограничений (финансовых временных и технологических) конвертируются в стратегический план автоматизации предприятия. 2.2.способ автоматизации: по участкам, направлениям, комплексная автоматизация; 2.3.долгосрочная техническая политика – комплекс внутренних стандартов, поддерживаемых на предприятии: типы стандартов на оборудование и ПО, перечень поставщиков и производителей базовых аппаратно-программных средств, на использование продукции которых ориентировано предприятие, перечень продуктов и линий продуктов, которые используются или которые предполагается использовать в области автоматизации; 2.4.Ограничения. К основным ограничениям, которые необходимо учитывать при выборе стратегии автоматизации, относятся следующие: -финансовые, -временные, -связанные с влиянием человеческого фактора, -технические. Финансовые ограничения определяются величиной инвестиций, которые предприятие способно сделать в развитие автоматизации. Этот тип ограничений универсален, так как остальные три вида могут быть частично конвертированы в финансовые. Временные ограничения обычно связаны со следующими факторами: -сменой технологий основного производства, -рыночной стратегией предприятия, государственным регулированием экономики. К ограничениям, связанным с влиянием человеческого фактора, относятся следующие: -корпоративная культура – отношение персонала к автоматизации: -особенности рынка труда: -трудовое законодательство, регулирующее процессы увольнения персонала, высвобождающегося в результате автоматизации. Корпоративная культура – это в первую очередь отношение персонала к автоматизации, привычка работать по стандартизированным процедурам и исполнительская дисциплина. Значительная часть информации вводится в информационную систему вручную в процессе производственной деятельности. Поэтому чрезвычайно важно соблюдение регламентов работ, особенно в части ввода информации. Игнорирование такого фактора, как корпоративная культура, приводило к тому, что надежды на автоматизированную систему, из которой можно легко получить всю необходимую в работе любого сотрудника информацию, сменялись пониманием суровой необходимости создания новых процедур работы, значительного увеличения нагрузки на персонал в первое время, необходимости обучения и , конечном итоге, возвращения к старым, проверенным способам с калькулятором и листом бумаги. Особенности рынка труда могут повлиять негативно, если существуют трудности с наймом персонала требуемого профиля и квалификации. Технические ограничения связаны с реальными возможностями предприятия: отсутствия помещения для размещения вычислительной техники, ограничения по использованию определенного вида оборудования и т.п. 2.5.Технологии При выборе стратегии автоматизации существенную роль играет состояние технологий. Если необходимой системы нет на рынке, тогда возможные решения ограничиваются следующими: -интеграция нескольких существующих систем; -разработка уникальной системы для предприятия; -откладывание решения о начале работ по автоматизации в ожидании появления требуемой системы. 2.6.Проблемы. Типичные проблемы, которые возникают при разработке стратегии автоматизации, как правило, связаны со следующими факторами: 2.6.1.состояние рынка информационных технологий; 2.6.2.определение эффективности инвестиций в информационные технологии; 2.6.3.необходимость реорганизации деятельности предприятия при внедрении информационных технологий. Внедрение системы автоматизации управления является сложным и довольно болезненным процессом. В ходе возникает великое множество больших и малых проблем. Некоторые из них можно предотвратить или свести к минимуму, тем самым, повысив эффективность самой системы. 2.6.3.1.Отсутствие постановки задачи. Внедрение системы напрямую зависит от того, какие цели и задачи ставят перед собой руководители предприятия. Если задачи неизвестны, то, что автоматизировать, тоже неизвестно. Попытка запрограммировать хаос не к чему хорошему не приводит. Поэтому, первое, что необходимо сделать для того, чтобы проект внедрения автоматизированной системы был успешным надо попытаться максимально формализовать все критерии которым должна удовлетворять система и описать все модули, входящие в нее. Т.е. в обязательном порядке нужно сделать предпроектное обследование предприятия. Заранее выявит все узкие места и попытаться оптимизировать некоторые функции. Работа эта трудоемкая и, возможно, чтобы сделать ее придется привлечь консультантов со стороны или создать группу из специалистов собственного предприятия. 2.6.3.2.Сопротивление сотрудников предприятия При внедрении информационных систем очень часто возникает активное сопротивление сотрудников предприятия.(тихий саботаж) Это может затянуть внедрение проекта на неопределенные сроки, а иногда и просто сорвать его. Корни этой проблемы кроются в простых человеческих слабостях: -в обыкновенном страхе перед всем новым. -в консерватизме. -опасение потерять свою работу. -повышение ответственности за свои действия. Поэтому руководители предприятия должны всячески помогать группе внедрения: вести разъяснительную работу с кадрами, издавать приказы и распоряжения,т.е. создать у своих сотрудников ощущение неизбежности внедрения. 2.6.3.3.Временное увеличение нагрузки на сотрудников. На некоторых этапах проекта внедрения временно возрастает нагрузка на сотрудников предприятия. Это связано с тем, что помимо выполнения обычных рабочих обязанностей, сотрудникам необходимо осваивать новые знания и технологии. Во время проведения опытной эксплуатации и при переходе к промышленной эксплуатации системы в течение некоторого времени приходится вести дела, как и в новой системе, так и продолжать ведение их традиционными способами (поддерживать бумажный документооборот и существовавшие ранее системы). В связи с этим, отдельные этапы проекта внедрения системы могут затягиваться под предлогом, что у сотрудников и так хватает срочной работы по прямому назначению, а освоение системы является второстепенным и отвлекающим занятием. В таких случаях руководителю предприятия, помимо ведения разъяснительной работы с уклоняющимися от освоения новых технологий сотрудников необходимо: -Повысить уровень мотивации сотрудников к освоению системы в форме поощрений и благодарностей; -Принять организационные меры к сокращению срока параллельного ведения дел. 2.6.3.4. Нецелесообразность собственных разработок На многих крупных предприятиях существуют системы, разработанные в 80-90 гг. в операционной системе DOS. Часто эти системы были созданы силами специалистов АСУ предприятия. К, сожалению, на сегодняшний день технологии автоматизации предприятия требует значительно больших трудозатрат, чем было раньше. Разработка программного обеспечения под Windows гораздо сложнее, чем под DOS. Современные базы данных требуют более высокой квалификации специалистов. Задачи, стоящие перед разработчиками значительно шире. И там, где справлялся один талантливый программист, сегодня требуется хорошо организованный коллектив их 10 человек. Вряд ли собственный отдел разработки сможет за приемлемые сроки создать и сопровождать высококачественную и полнофункциональную систему. Сюда же накладываются проблемы текучести кадров, ответственности за разработку проекта. Поэтому лучше выбрать автоматизированную систему управления предприятием, имеющую положительный опыт внедрения. У программистов есть такая присказка, что внедрение системы как ремонт – его невозможно закончить, а можно лишь прекратить. Так что внедрение, по сути, никогда не закончится, потому что система должна постоянно расти, развиваться и совершенствоваться вместе со своим предприятием. 3.Классификация ИС. 3.1.В зависимости от характера обработки информации в ИС на различных уровнях управления (оперативном, тактическом и стратегическом) выделяются следующие типы информационных систем: -системы обработки данных ( EDP – electronic data processing); -информационная система управления ( MIS – management information system ); -система поддержки принятия решений ( DDS – decision support system). 3.1.1.Системы обработки данных (СОД) предназначены для учета и оперативного регулирования хозяйственных операций, подготовки стандартных документов для внешней среды (счетов, накладных, платежных поручений). Горизонт оперативного управления хозяйственными процессами составляет от одного до несколько дней и реализует регистрацию и обработку событий, например оформление и мониторинг выполнения заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д. Эти задачи имеют итеративный, регулярный характер, выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.) и связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных. 3.1.2.Информационные системы управления (ИСУ) ориентированы на тактический уровень управления: среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев), например анализ и планирование поставок, сбыта, составление производственных программ. Для данного класса задач характерны регламентированность ( периодическая повторяемость ) формирования результатных документов и четко определенный алгоритм решения задач, например свод заказов для формирования производственной программы и определение потребности в комплектующих деталях и материалах на основе спецификации изделий. Решение подобных задач предназначено для руководителей различных служб предприятий (отделов материально-технического снабжения и сбыта, цехов и т.д.). Задачи решаются на основе накопленной базы оперативных данных. 3.1.3.Системы поддержки принятия решений (СППР ) используются в основном на верхнем уровне управления ( руководства фирм, предприятий, организаций ), имеющего стратегического долгосрочное значение в течение года или нескольких лет. К таким задачам относятся формирование стратегических целей, планирование привлечения ресурсов, источников финансирования, выбор места размещения предприятий и т.д. Реже задачи класса СППР решаются на тактическом уровне, например при выборе поставщиков или заключении контрактов с клиентами. Задачи СППР имеют, как правило, нерегулярный характер. Для задач СППР свойственны недостаточность имеющейся информации, ее противоречивость и нечеткость, преобладание качественных оценок целей и ограничений, слабая формализованность алгоритмов решения. В качестве инструментов обобщения чаще всего используются средства составления аналитических отчетов произвольной формы, методы статистического анализа, математического и имитационного моделирования. Развитием систем ППР являются экспертные системы (ЭС), использующие знания экспертов, представленные в некотором формальном виде. При этом используются базы обобщенной информации, информационные хранилища, базы знаний о правилах и моделях принятия решений. Идеальной считается ИС, которая включает все три типа перечисленных информационных систем. 3.2. В зависимости от охвата функций и уровней управления различают корпоративные (интегрированные) и локальные ИС. 3.2.1.Корпоративная (интегрированная) ИС автоматизирует все функции управления на всех уровнях управления. Такая ИС является многопользовательской, функционирует в распределенной вычислительной сети. 3.2.2.Локальная ИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ИС может быть однопользовательской, функционирующей в отдельных подразделениях системы управления. 3.3. В зависимости от технологических особенностей обработки информации обычно выделяют функциональные и обеспечивающие подсистемы. 3.3.1 .Одним из основных свойств ИС является делимость на подсистемы. Выделяют: -функциональные подсистемы ЭИС, которые информационно обслуживают определенные виды деятельности предприятия, характерные для структурных подразделений и функций управления (управление производством, технико-экономическое планирование, бухучет и др.). -обеспечивающие подсистемы ЭИС, которые играют вспомогательную роль по отношению к функциональным подсистемам: системного программного обеспечения, технического обеспечения, компьютерных сетей и обмена данными. Делимость на подсистемы имеет ряд достоинств с точки зрения разработки и эксплуатации ЭИС, к которым относятся: -упрощение разработки и модернизации ИС в результате специализации групп проектировщиков по подсистемам; -упрощение внедрения и поставки готовых подсистем в соответствии с очередностью выполнения работ; -упрощение эксплуатации ИС вследствие специализации работников предметной области. 3.3.2. Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем, таких, как информационная, программная, математическая, техническая, технологическая, организационная и правовая подсистемы. Лекция 4.Выбор управленческой информационной системы. Классификация систем автоматизации управления предприятием. Минимальный перечень требований к системе, претендующей на “звание” корпоративной информационной системы. Выбор системы. Основные факторы успеха. Типичные ошибки. 1.Классификация систем автоматизации управления предприятием. 1.1.В зависимости от технологии создания можно выделить два типа систем: заказные и адаптируемые Под заказными или уникальными системами обычно понимаются системы, создаваемые для конкретного предприятия, не имеющие аналогов и не подлежащие в дальнейшем тиражированию. Заказные системы используются либо для автоматизации деятельности предприятий с уникальными характеристиками, либо для решения крайне ограниченного круга специальных задач в силу своей высокой стоимости и значительных сроков разработки и внедрения. К адаптируемым системам в той или иной степени можно отнести все многообразие систем, предлагаемых сегодня на рынке, например: R3, BAAN, Галактика и др. Проблема адаптации программного обеспечения АСУП, т.е. приспособления к условиям работы на конкретном предприятии, была осознана с самого начала работ по автоматизации управления. Дальнейшее развитие методов и средств адаптации базовых систем направлено на достижение следующих целей: -повышение уровня автоматизации проектирования и внедрения систем. -обеспечение непрерывного управления конфигурацией и параметрами системы на всех стадиях ее жизненного цикла. -сокращение сроков внесения изменений в конфигурацию и параметры системы по мере модернизации производственного процесса и управления. -совмещение типовых решений, проверенных практикой, с решениями, зависящими от конкретных условий предприятия. На рынке адаптируемых систем, способных обеспечить эффективное управление организацией, представлены как российские, так и зарубежные системы различного назначения. 1.2.В зависимости от масштаба можно выделить локальные и интегрированные системы. Локальные системы ориентированы на автоматизацию отдельных функций управления. Интегрированные системы управления охватывают весь комплекс функций управления предприятием. 1.3.Если говорить о реальном секторе рынка компьютерных адаптируемых систем, то можно выделить системы двух классов: -финансово-управленческие системы -локальные; -малые интегрированные; -производственные системы -средние; -крупные интегрированные; Назначение финансово – управленческих систем: ведение учета по одному или нескольким направлениям (бухгалтерия, сбыт, склады, учет кадров и т.д.), управление финансовыми потоками. Свойства финансово - управленческих систем: • Универсальность. • Небольшой цикл внедрения. • Имеются ”коробочные’ варианты. • Гибкость в адаптации к нуждам конкретного предприятия. • Способность работать на персональных компьютерах в обычных сетях передачи данных Novell Netware или Windows NT. • Использование простых средств разработки (Clipper, FoxPro, dBase, Paradox). • Снижение уровня эффективности при работе на сложных конфигурациях сети и при увеличении объемов обрабатываемых данных. Назначение производственных систем: управление и планирование производственного процесса. Свойства производственных систем: • Учетные функции глубоко проработаны и выполняют вспомогательную роль. • Более сложны в установке (цикл внедрения может занимать от 6-9 месяцев до полутора лет и более). • Часто ориентированы на одну или несколько отраслей и / или типов производства • Различны для разных типов организации производственного процесса (единичное, серийное, массовое производство). • Наличие встроенных бизнес-моделей производства • Производственные системы по многим параметрам значительно более жесткие, чем финансово-управленческие • Основными механизмами управления являются планирование и оптимальное управление производственными процессом • Охватывают планирование, закупки, производство, запасы, продажи, финансовые потоки и многие другие аспекты • При увеличении сложности и широты охвата функций предприятия системой возрастают требования к технической инфраструктуре и компьютерной платформе • Разработаны с использованием промышленных баз данных • В большинстве случаев используется технология “клиент-сервер”. Классификация рынка информационных систем Локальные Малые интегрированные Средние интегрированные Крупные системы системы системы интегри- рованные системы Предс- 1с Concorde XAL JD Edwards SAP/R3 тавите- БЭСТ Exact NS-2000 (SAP AG) ли групп “Инотек” Platinum PRO/ (Robertson&Blums) BAAN Инфин MIS MFG-PRO (QAD/BMS) (BAAN) “Инфософт” Scala Sun Systems SyteLine BPCS “Супер- БОСС- (СОКАП/SYMIX) (ITS/SSA) Менеджер” Корпорация Oracle “Турбо- Галактика/ Application Бухгалтер” Парус (Oracle) “Инфо- Ресурс Бухгалтер” Эталон +более 100 систем 2.Минимальный перечень требований к системе, претендующей на “звание” корпоративной информационной системы Очевидно, что оценка качества информационной системы – процесс неоднозначный и многокритериальный. Качественность информационной системы предполагает, что она будет обладать рядом свойств. Поэтому для практики полезнее определить эти свойства. Мы воспользовались работой Е.В.Дворниковой, размещенной в Internet, в которой определен минимальный перечень требований к системе, претендующей на “звание” корпоративной информационной системы: 2.1.Функциональная полнота системы: -выполнение международных стандартов управленческого учета-MRP2, ERP, CSRP -автоматизация в рамках системы решения задач: • планирования, бюджетирования, прогнозирования • оперативного (управленческого) учета • бухгалтерского учета • статистического учета • финансово-экономического анализа -формирование отчетов и ведение учета одновременно по российским и международным стандартам (IAS и GAAP) -общими характеристиками функциональной полноты корпоративной информационной системы является количество однократно учитываемых параметров деятельности предприятия. Для КИС количество этих параметров должно быть примерно следующим: • Количество учитываемых параметров 2000-10000 • Количество таблиц баз данных 800-3000 2.2.Локализация информационной системы: -функциональная (учет особенностей российского законодательства и системы расчетов); -лингвистическая (интерфейс, система помощи и документация на русском языке). 2.3.Система должна обеспечивать надежную защиту информации. Для этого необходимы: -парольная система разграничения доступа к данным и функциям -многоуровневая система защиты данных, включающая средства авторизации вводимой и корректируемой информации, регистрация времени ввода и модификации данных, протокол удалений -программно-аппаратные средства шифровки данных, сертифицированные ФАПСИ. 2.4.Реализация удаленного доступа и работы в распределенных сетях. 2.5.Наличие инструментальных средств адаптации и сопровождения системы: -изменение структуры и функций бизнес-процессов; -изменение информационного пространства (изменение структуры, добавление или удаление БД, модификация полей таблиц, связей, индексов и т.п.); -изменение интерфейсов ввода, просмотра и корректировки информации; -изменение организационного и функционального наполнения рабочего места пользователя; -генератор произвольных отчетов; -генератор сложных хозяйственных операций; -генератор форм (в том числе стандартизованных). 2.6.Обеспечение обмена данными между ранее разработанными ИС и другими программными продуктами, функционирующими на предприятии. 2.7.Возможность консолидации информации: -на уровне предприятий – для объединения информации филиалов, дочерних компаний, предприятий, входящих в холдинг, и т.п.; -на уровне отдельных задач; -на уровне временных периодов – для выполнения анализа изменения тех или иных показателей за период, превышающий отчетный. 2.8.Наличие специальных средств анализа состояния системы в процессе эксплуатации: -анализ архитектуры баз данных; -анализ алгоритмов; -анализ статистики количества обработанной информации (количество записей, документов, проводок; объем дисковой памяти); -журнал выполненных операций; -список работающих станций, внутрисистемная почта. 3.Выбор системы Проблема выбора – одна из ключевых в деятельности человека. Проблема выбора системы автоматизации управления предприятием возникает практически всегда, когда руководство, ощущая потребность в современном инструменте управления, в то же время не может четко сформулировать основные требования к системе. Основным критерием, которым следует руководствоваться при выборе системы, должен быть критерий удовлетворения потребностей бизнеса предприятия. Потребности бизнеса формулируются в терминах бизнеса. Основные критерии выбора системы: -функциональные возможности; -совокупная стоимость владения; -перспективы развития, поддержки и интеграции; -технические характеристики. При выборе системы требования, сформулированные в терминах бизнеса, должны быть конвертированы в технические и экономические требования к системе, сформулированные в соответствующих терминах. 3.1.Для того чтобы определить достаточность функциональных возможностей системы, необходимы два компонента: -Стратегия развития бизнеса и конкретное описание бизнеса. -Формализованное описание деятельности предприятия. Лучше всего, если это будут модели деятельности предприятия, выполненные согласно методикам структурного анализа: диаграммы согласно стандартам IDEF0 или IDEF3; диаграммы потоков данных или модели бизнес-процессов. Наиболее просто проблема определения достаточности функциональной полноты решаются для финансово - управленческих систем. Для производственных систем определяются: -Какие типы производства может поддерживать система (разработка на заказ – представляет собой дальнейшее развитие проектно-ориентированного производства; сборка на заказ – предложение клиента продукции массового производства; работа на склад – поддержание требуемого уровня товарно-материальных запасов в сочетании с организацией поставок со склада; повторяющееся производство – производство, организованное в соответствии с идеологией “ точно – в – срок “; процессное производство). -Поддерживает ли система управление цепью поставок. То есть рассматривается возможность ERP – системы управлять поставками, материально-техническими снабжением (логистикой) и спросом. -Как система поддерживает производственные поставки, а также электронные средства поставки. -Насколько полно система управляет процессом материально-технического снабжения, а также складированием продукции и планированием ее доставки. -Как система учитывает работу с клиентами. Требуется оценить, как в системе поддерживается планирование спроса, автоматизация работы с посредниками и торговыми агентами, насколько гибко осуществляется обработка заказов клиентов, а также осуществляется учет сервисного обслуживания. 3.2.Совокупная стоимость владения (TCO- Total Cost of Ownership) информационной системой – сравнительно новое понятие, которому в последнее время уделяется самое пристальное внимание в литературе. При выборе новой информационной системы между альтернативными существующему решению вариантами необходимо оценить совокупную стоимость владения для каждого предлагаемого варианта. .Под совокупной стоимостью владения понимается сумма прямых и косвенных затрат, которые несет владелец системы за период жизненного цикла последней. При этом жизненный цикл, на котором оцениваются прямые и косвенные затраты, должен включать: -время жизни существующей на предприятии системы. -время проектирования новой системы. -время на закупку и внедрение элементов новой системы. -время эксплуатации новой системы, которое необходимо ограничить сроком возраста 90% вложенных инвестиций за счет прибыли от эксплуатации этой системы. Вариант информационной системы с более коротким жизненным циклом предпочтителен для дальнейшего использования. 3.3. Перспективы развития и поддержки в основном определяются поставщиком решения и тем комплексом стандартов, который заложен в систему и составляющие ее компоненты. Самая большая проблема может возникнуть у предприятия при выборе фирмы. Надо выбрать такую, которая не исчезнет через некоторое время. При этом надеяться на нормальное сопровождение, а уж тем более на переход к новым версиям программного продукта не приходится. Малейшее изменение российского законодательства – и надо покупать новую систему! Устойчивость поставщика решения и поставщиков отдельных компонентов определяется в первую очередь временем существования их на рынке и долей рынка (как мирового, так и российского), которую они занимают. Важным фактором является форма, в которой осуществляется присутствие на российском рынке: наличие авторизированных учебных центров, “ горячих линий” для консультаций. 3.4.Технические характеристики К техническим характеристикам системы относятся следующие: 3.4.1.Поиск информации и удобство работы пользователей. Простота и удобство работы иногда могут оказаться решающим фактором при выборе системы, особенно если сравнивается несколько практически аналогичных программных продуктов. Кроме того, данный критерий косвенно свидетельствует о квалификации компании-разработчика. 3.4.2. Гибкость системы является важным критерием ее выбора в том случае, если предприятие не собирается стоять на месте, т.е. если оно планирует развиваться, совершенствовать свою деятельность или просто функционирует в условиях постоянного изменения внешних условий (например, отечественного законодательства). Отсутствие гибкости у системы приводит к необходимости постоянного привлечения дорогостоящих специалистов фирмы-разработчика или компании-интегратора для настройки системы автоматизации управления предприятием под меняющиеся потребности деятельности. Такое положение может свести на нет весь финансовый эффект от внедрения системы. 3.4.3. О легкости внедрения имеет смысл говорить о том случае, если предприятие жестко ограничено в конечных сроках и силах, необходимых для приведения системы в рабочее состояние. Однако забывать об этом критерии ни в коем случае нельзя, иначе внедрение автоматизированной системы рискует превратиться в бесконечный процесс. 3.4.4. Тиражируемость системы (или, другими словами, количество ее внедрений) является серьезным аргументом, который помогает принять окончательное решение при выборе системы автоматизации. Так, если система не привлекла внимания ни одного из предприятий (а желательно, чтобы она была внедрена на предприятии аналогичного профиля), это должно по крайней мере насторожить. А если система внедрена, то общение с персоналом организации, в которой она успешно эксплуатируется, позволит избежать возможных ошибок. 3.4.5.Возможность интеграции с другими системами определяется совокупностью поддерживаемых стандартов. 3.4.6.Надежность, особенно в части выполнения критических бизнес-приложений, способность к восстановлению при сбоях оборудования, наличие средств архивирования и резервного копирования данных. 3.4.7.Безопасность – наличие средств защиты от преднамеренных и непреднамеренных технических нападений. 3.4.8.Масштабируемость - возможность наращивания при необходимости функциональных возможностей и увеличение числа пользователей. 4.Основные факторы успеха Среди основных факторов, повышающих вероятность успеха внедрения ИСУП, я бы в первую очередь назвал следующие: • понимание необходимости внедрения интегрированных ИС; • понимание основ построения интегрированных ИС; • готовность к четкой организации проекта обследования и внедрения; • готовность к выделению квалифицированных ресурсов; • готовность предприятия к внедрению; • готовность к изменениям. 4.1Понимание необходимости внедрения интегрированных ИС Необходимо ли внедрение интегрированных информационных систем на предприятиях? Для западных предприятий вопроса в такой постановке не существует. Система управления предприятием в обязательном порядке строится на базе оперативной информации, сопровождающей процессы планирования, учета и управления. Накопленная информация за прошлые периоды является аналитической базой для контроля и оптимизации деятельности. Интегрированная информационная система помимо предоставления возможности оперативного сбора, хранения и анализа данных требует высокой исполнительской дисциплины со стороны сотрудников предприятия и обеспечивает построение ясной структуры и последовательности процессов деятельности. 4.2.Понимание основ построения интегрированных ИС Прежде, чем приступать к внедрению ИСУП, руководящий состав предприятия должен ознакомиться с основными теоретическими принципами управления, заложенными в нее в качестве функциональной базы. За последнее десятилетие ведущими мировыми компаниями наработаны теоретические референтные модели деятельности предприятий самых различных направлений бизнеса (торговые, дистрибьютерские, производственные, добывающие и т.д.). Выделены и сформированы основные требования к функциональным подсистемам, реализующим процессы управления финансами, производством, снабжением, сбытом, проектными работами, техническим обслуживанием и т.д. Формализована и программно реализована логика процессов планирования, учета и контроля. 4.3.Готовность к четкой организации проекта обследования и внедрения Внедрение ИСУП осуществляется в рамках специально организованного проекта со следующими основными стадиями: • обследование предприятия; • выверка и формирование основной нормативно-справочной информации; • описание и оптимизация процессов деятельности предприятия по направлениям, подвергающимся автоматизации; • настройка системы на процессы деятельности предприятия и подстройка процессов деятельности под основные требования системы; • проведение опытной эксплуатации; • ввод в промышленную эксплуатацию; • сопровождение промышленной эксплуатации. Совершенно очевидно, что без строгой организации проекта и планомерного выполнения необходимых работ, добиться успешного внедрения невозможно. В то же время любые инициативы, предполагающие долгосрочную реализацию задуманного, потребуют конкретных действий, таких как: • формирование структуры управления проектом; определение регламента контроля хода и качества реализации планирования и выделения ресурсов; • четкое ведение проектной документации; своевременная реакция на отклонение от графика и принятия необходимых мер по устранению недостатков. Принимая во внимание необходимость использования результатов обследования и внедрения на предприятии в течение продолжительного периода времени, команда сотрудников, привлекаемая к проекту, с самого начала должна активно заниматься выполнением всех работ с целью накопления опыта и приобретения знаний по организации системы управления для последующего эффективного использования и сопровождения ИС. Делегирование выполнения проекта силам нанимаемых консультантов может дать только промежуточные положительные результаты, выраженные в отчетах, рекомендациях и мероприятиях по обучению. Полагаться же на полноценное внедрение системы при таком подходе - заранее обрекать себя на провал. 4.4.Готовность к выделению квалифицированных ресурсов Внедрению ИСУП в особенности на промышленных предприятиях всегда сопутствует реорганизация существующих процессов деятельности. Слово "реинжиниринг" у многих вызывает идиосинкразию, так как часто связывается с попытками внести дополнительную путаницу в существующий беспорядок. На наш взгляд, не нужно с самого начала ставить задачу глобального преобразования всего предприятия в связи с внедрением новых информационных технологий. Прежде всего следует сформировать работоспособную, квалифицированную и инициативную команду, способную к восприятию и приложению на практике перспективных технологий. По мере анализа и документирования процессов деятельности, использования инструментов моделирования, тесного общения с руководством предприятия и согласования необходимых изменений, процесс "реинжиниринга" может пройти относительно безболезненно и постепенно, не вызывая катастрофического отторжения новаций у руководителей среднего звена и исполнителей. Руководство предприятия должно осознавать, что уровень квалификации и способности сотрудников, привлекаемых к внедрению, будет непосредственно влиять на окончательный результат. Чем серьезнее отношение руководства к подбору персонала, тем большую отдачу от внедрения они получат. 4.5.Готовность предприятия к внедрению В соответствии с вышесказанным следует подчеркнуть, что руководство предприятия должно быть заинтересованно в выделении квалифицированных специалистов по информационной поддержке процессов управления предприятием. Формирование такого коллектива возможно при одном условии - организация и выполнение внедрения осуществляется самим предприятием. Необходимо четко разделять виды деятельности: • консультационное сопровождение внедрения ИС; • непосредственно внедрение ИС. Консультационное сопровождение внедрения подразумевает в основном обучение и консультации (целевое обучение) по вопросам настройки, особенностей применения и использования системы для решения конкретных задач на этапе обследования и внедрения. Консультационное сопровождение выполняется нанимаемыми консультантами и руководителем проекта со стороны внешнего исполнителя. Непосредственным внедрением (подготовка и заведение нормативно-справочной информации, моделирование процессов деятельности, осуществление опытной эксплуатации и перевод в промышленную эксплуатацию) должны заниматься сотрудники команды от предприятия. Это принципиально необходимо, поскольку консультанты - временный состав на предприятии. В процессе внедрения предприятие должно получить не только настроенную и функционирующую систему, но и, что не менее важно, профессионально подготовленных людей, способных самостоятельно и эффективно эксплуатировать и сопровождать ИС. Подготовленные сотрудники должны стать реальной опорой руководителей предприятия различного уровня ответственности. 4.6.Готовность к изменениям Как уже отмечалось ранее внедрение ИС всегда сопровождается привнесением изменений как в структуру предприятия, так и в процессы деятельности. Такие изменения не должны проводиться с потерей качества управления, поэтому предлагаемые изменения обосновываются и согласовываются с руководством предприятия. Основной критерий необходимости изменений - их целесообразность с точки зрения процесса управления в целом. Основная предпосылка успешного проведения изменений - конструктивность позиции руководящих лиц предприятия и их понимание, зачем все это нужно. 5.Основные причины неудач внедрения ИС • Недооценка сотрудниками предприятия сложности процесса внедрения ИСУП и организационной составляющей проекта; • Неготовность предприятия в целом к структурным изменениям и изменениям процессов деятельности; • Непонимание разницы между консультационным сопровождением процесса внедрения и практическими работами по внедрению; • Перенос центра тяжести внедрения на службы АСУ. Какие ошибки чаще всего совершают управленцы, выбирая ERP систеу (Александр Гомонов – директор по развитию бизнеса компании “ЭпикРус”) Ошибка 1. "Найти то, не знаем что..." Довольно распространненая на сегодняшний день ошибка - это отсутствие четких представлений о том, какого типа программное обеспечение должно быть внедрено. Нередко встречаются случаи когда, компания рассматривает в качестве своей корпоративной системы какую-нибудь простенькую бухгалтерскую программку и одновременно - мощный ERP-комплекс. Поэтому перед тем как начать поиск конкретного поставщика программного продукта необходимо четко понять, во-первых, круг задач, которые этот продукт должен решать, а во-вторых, - примерные суммы, которые компания готова потратить на автоматизацию бизнеса. Ошибка 2. "Взять вино без бутылки..." Среди основных заблуждений при выборе системы можно назвать ориентацию клиента только на сам программный продукт, без учета возможностей и опыта компании, которая его поставляет и внедряет. В результате может возникнуть ситуация, когда предприятие приобретает систему, а ее поставщик оказывается не в состоянии обеспечить ни внедрение, ни техническую поддержку, ни обновление версий. Ошибка 3. "Новое вино в старые мехи..." Некоторые управленцы утверждают: "Система должна автоматизировать мой бизнес таким, какой он есть". А на самом деле ему необходим реинжиниринг бизнес-процессов. Внедрение ERP-системы автоматизирует имеющиеся бизнес-процессы, однако, если в этих бизнес-процессах много противоречий и они неформализованы, то их, скорее всего, будет очень сложно (а зачастую невозможно) автоматизировать. Ошибка 4. "Всуну дискету и все зарабатает..." Еще одна тенденция - желание приобрести систему, "которую не нужно внедрять". Такие продукты существуют на нашем рынке. Однако полноценная ERP-система затрагивает специфику и особенности компании, поэтому необходим процесс внедрения. Ошибка 5. "Куплю костюмчик я по моде..." Иногда к негативным результатам приводит желание внедрить ERP-систему на "голом" месте, то есть от практически полного отсутствия автоматизации перейти сразу же к самым мощным системам (при таком подходе существенную роль играет не столько реальные потребности компании, сколь стремление "не отставать от моды"). Бывают ситуации, когда компания затрачивает на автоматизацию огромные деньги, а потом использует лишь несколько процентов от возможностей установленной системы. Ошибка 6. "А кому все это нужно!?..." Некоторые руководители, считают, что выбором корпоративной информационной системы должны только сотрудники IT-службы компании: мол, но программисты, пусть сами и разбираются, пусть найдут себе "игрушку" получше... Между тем, автоматизация бизнеса нужна в первую очередь именно руководству компании и оно обязательно должно принимать участие в принятие решений. Ошибка 7. "Где бы еще сэкономить..." Существует заблуждение "обратное" ошибке 5 - приобретать самую простую и дешевую систему, которая позволяет решить лишь "горячие" задачи. При этом часто не задумываются о возможностях масштабирования системы и расширении ее функциональности. В итоге получается, как в известной поговорке о том, что скупой платит дважды. Лекция 5. Принятие решений о приобретении ИТ – продукта. Проведение конкурса. Использование консалтинга. Оценка предложений поставщиков. 1.Понятие тендера. Понятие тендера в отечественной практике выбора корпоративных информационных систем по сути не имеет строгой юридической базы, и большинство участников рынка понимают под ним прежде всего некую формализованную процедуру, цель которой — выбор программного продукта. Конечно, для того, чтобы термин “правильное решение” вообще имел смысл, должны быть поставлены адекватные цели (а их постановка, кстати, также может оказаться частью тендерной процедуры). Многочисленные беседы с клиентами, внедряющими КИС, приводят к выводу о том, что тендер часто отождествляют с наличием нескольких альтернативных вариантов внедрения ПО, вовсе оставляя в стороне вопрос о методологии. Вряд ли данную точку зрения можно признать правильной, но большого вреда она не наносит. Отсутствие жесткой процедуры, нацеленной на получение максимально объективного результата, вовсе не означает, что цель не будет достигнута. Именно это мы часто наблюдаем на практике. Таким образом, понятие “тендер” можно определить как четко определенную последовательность организационных мероприятий, направленных на достижение максимальной объективности, необходимой для принятия правильного решения. На вопрос о том, целесообразно ли проведение тендера в любой ситуации, отнюдь не всегда можно дать однозначно утвердительный ответ. Набор факторов, которые говорят в пользу или же, наоборот, против проведения тендера, может определяться как внутренними традициями предприятия, так и необходимостью затрат определенных ресурсов на проведение тендера. “Стоимость проведения тендера может составлять 20—30 тыс. долл., и основная часть указанной суммы — это рабочее время высшего руководства предприятия. Если стоимость проекта превышает полмиллиона долларов, то тендер проводить однозначно стоит, поскольку слишком велика цена неправильных решений. Если же она оценивается величиной, меньшей 100 тыс. долл., мне кажется, что выбирать систему следует стандартным путем”. Приведенные значения стоимости тендера кому-то могут показаться несколько завышенными, но, скорее всего, они относятся к крупным проектам, на которые в основном ориентирована компания. Тендер может быть как открытый, так и закрытый, Если вы хотите привлечь поставщиков к работе в одной для вас области, и еще неизвестно, какая из компаний, работающих в этом направлении, окажется достойным партнером, то целесообразно проведение открытого тендера, так как закрытый тендер предполагает реальный риск обокрасть самих себя. Закрытый тендер проще. Он проводится в случаях, когда количество поставщиков ограничено или когда круг поставщиков достаточно хорошо знаком. Зачем устраивать открытые тендеры, если пальцев одной руки хватит, чтобы перечислить лидеров в отдельно взятой рыночной нише? Рассылать техническое задание всем подряд глупо: зачем всем знать, какие в компании бизнес-процессы. Поскольку партнеры конкурируют между собой, есть возможность выбирать самые выгодные варианты. Справедливость закрытого тендера обеспечивается строгим, как и при проведении открытого тендера, соблюдением правил. Процесс облегчается тем, что отпадает необходимость в жестком выполнении целого ряда требований, предусмотренных законодательством и обязательных для открытых тендеров. В частности, не нужно просматривать огромное количество предложений. Для проведения тендера создается тендерный комитет, в задачу которого входит детальная оценка функциональности продуктов-финалистов. В комиссии однозначно должны быть представлены руководители всех ключевых подразделений заказчика. Более того, должно быть обеспечено одинаковое отношение ко всем участникам. “Абсолютно недопустима ситуация, при которой одну систему смотрит только главный бухгалтер, а вторую, например, начальник производства”. 2.Можно выделить три этапа проведения тендера 2.1.На первом этапе осуществляется подготовка и рассылка тендерных писем, форма которых может быть различной. “Первое письмо в размере одной-двух страниц должно рассылаться максимальному числу поставщиков и содержать набор вопросов, относящихся к основным критериям выбора системы, или могут содержать достаточно развернутые тезисы, в повествовательной форме характеризующие как состояние самого предприятия, так и набор стоящих перед ним задач. Такая форма обычно практикуется в двух случаях: если организация тендера проводится целиком силами внешних консультантов, а также в нечасто встречающихся ситуациях, когда предметом выбора является вся информационная инфраструктура предприятия, а не только корпоративная информационная система Конечно, в реальных условиях российского рынка этих компаний будет не более трех-четырех десятков, если даже постараться задействовать максимальное их число. Как правило, определяется крайний срок подачи предложений (дату и время). В зависимости от того, о каком конкурсе идет речь, мы получаем эти предложения по электронной почте либо в закрытом конверте. Специалисты анализируют полученную от партнеров информацию, затем матрица суммирует и формируется результат, на основе которого мы формулируем собственное предложение. Оно выносится на маркетинговую комиссию или на комитет по информатизации. Эти люди знакомятся с методологией выбора подрядной организации или поставщика ИТ. Если у них нет сомнений в том, что конкурс проведен в соответствии с заявленными правилами, то предложение подтверждается. Если комитет находит, что по каким-либо причинам будет разумнее “переиграть” конкурс, то процесс запускается повторно. Окончательный выбор производится на основе коллегиального решения. 2.2.Ко второму этапу тендера, по практически единодушному мнению специалистов, может допускаться лишь ограниченное количество продуктов и соответственно фирм-поставщиков, поскольку этот этап предполагает значительно более тесные и неформальные контакты заказчика с партнером, предлагающим предприятию систему управления. На данном этапе должно остаться всего несколько компаний, а выбор начинает строиться на основе более сложного и творческого подхода, поскольку проводится посредством многокритериальной оценки, а не путем отсечения продуктов, явно не удовлетворяющих клиента по функциональности. Определяется несколько фирм, с которыми вообще предстоит иметь дело в дальнейшем. При этом крайне желательно, чтобы присланные ответы были заверены подписью генерального директора компании-поставщика. Последнее условие на практике оказывается далеко не второстепенным и, очевидно, диктуется необходимостью с самого начала придать последующей процедуре более весомый статус. Хорошо известно, что на основе положительных ответов впоследствии могут формулироваться конкретные пункты контрактных обязательств, а невыполнение каждого из них чревато для поставщика крайне негативными юридическими последствиями. Возможно и изначальное сужение круга участников, которое зависит от квалификации и опыта заказчика или консультационной фирмы, привлеченной для проведения тендера. “Пусть, например, мы хотим заменить сотню рабочих станций в одном из регионов. Это довольно значительные инвестиции. Мы рассылаем техническое задание четырем или пяти партнерам, работающим с нами по этому направлению, и объявляем им нашу систему оценки участников тендера. В ее основе лежит матрица с перечисленными в ней факторами, которые мы считаем важными в данном случае. В их числе могут быть стоимость, надежность и скорость поставки, предшествующие отношения с нами и т.д. Затем мы получаем и оцениваем предложения наших партнеров”. На этой стадии заказчик куда сильнее оказывается вовлечен в работу по выбору системы, которая к тому же становится и более интеллектуальной. Как следствие, возрастает роль тендерной комиссии. Поскольку на данном этапе речь идет о вещах более тонких, чем просто наличие или отсутствие той или иной функциональности, почти всегда стараются найти компромиссные решения. Например, у одной компании может быть меньше опыта внедрения в нужной отрасли, но, скажем, лучше поддержка. Все это диктует необходимость аккуратного подхода к оценке оптимальности выбираемого решения. “Мы стараемся, чтобы на этапе очной работы с поставщиками вся процедура была максимально открытой и каждый из представителей тендерной комиссии в любой момент мог высказать свое мнение. Если с самого начала будут какие-то недоговоренности, то и без того сложный процесс внедрения усложнится в несколько раз”, — утверждает Сергей Рогинский. 2.3.На третьем этапе остаются, как правило, всего две компании. Принципиально этот этап не отличается от предыдущего, если не считать того, что оценка решение в этом случае предельно тщательно, а отношения поставщик - клиент часто еще более неформальны. На этом этапе попытка заказчика максимально “прогнуть” цены в свою пользу — вполне обычная форма взаимных контактов. Один из популярных приемов, практика применения которого напрямую связана с тонкостями оценки систем при детальном знакомстве с ними, а также в определенной степени с не слишком большой щепетильностью поставщика при ответах на поставленные вопросы, — выполнение им тестовых примеров. “Для того, чтобы понять, насколько правильно разработчик и поставщик отвечают на те вопросы, которые заданы в тендерном письме, при проведении тендеров используется практика тестовых примеров, — говорит Сергей Рогинский.— Их необходимо составить так, чтобы результат выполнения примера четко отвечал на поставленный вопрос и вместе с тем выполнение примера не потребовало от разработчика или поставщика больших усилий”. Подчеркнем, что цель подобных примеров — все-таки стремление проникнуть в детали функционала системы, которые могут быть истолкованы либо неполно, либо вообще неправильно. К числу таких свойств специалисты относят, например, тезис о поддержке многовалютности. Вообще говоря, разглядеть в предлагаемом решении потенциально спорные моменты да еще грамотно составить сам тестовый пример достаточно сложно, и выполнение подобных работ требует от организатора тендера, будь то сам заказчик или консультант, и опыта, и квалификации. Имеет смысл ставить данный вопрос только тогда, когда речь идет о первом внедрении системы в отрасли. Если же на производстве подобного типа программное решение уже где-то используется, разумно выяснять нюансы функциональных свойств систем на основе реально работающего прототипа. 3.Использование консультанта при проведении тендера. Еще один ключевой вопрос организации процедуры проведения тендера связан с тем, насколько необходимо присутствие в ней консультационной компании. А если без консультанта все-таки не обойтись, его роль и степень участия в тендере должны быть четко обоснованы. Часто подразумевается, что, если консультант берет на себя труд и ответственность по выбору системы для заказчика, его роль только этим не ограничивается. На этапе, предшествующем тендеру, он принимает участие в формулировке требований к программному обеспечению, активно влияя на мнение заказчика, а впоследствии займется внедрением системы вплоть до полного достижения целей, поставленных на первоначальном этапе, и будет к тому же отвечать за их достижение. Более того, в принципе не лишен практического смысла сценарий, когда консультант берет на себя всю работу по выбору и внедрению ПО, максимально освобождая от этих забот клиента и неся таким образом исключительную ответственность за достижение конечного результата. К тому же в данном случае вполне можно вести речь о предоставлении финансовых гарантий — а это, по сути, идеальная форма ответственности сторонней фирмы перед заказчиком. И пусть такой вариант на практике пока не встречается, некая промежуточная ситуация все же реализуема. Нередки случаи, когда консультант полностью проводит селекцию претендентов на первом, формальном этапе тендера, а заказчик подключается к работе впоследствии, когда требуется более детальный подход. Такая ситуация имела место, например, на Нижнетагильском металлургическом комбинате, одном из первых крупных клиентов SAP в России. Перспективы участия консультанта в последующих стадиях проекта часто влияют и на тактику проведения им тендерной процедуры. Причем создается впечатление, что за этим кроется ряд неоднозначных моментов. Дело в том, что в случае привлечения консультационной компании к внедрению выбранной системы (а это, как мы выяснили, в принципе позитивная ситуация) отдельные этапы работы могут выполняться фактически авансом. В частности, это относится к обследованию бизнес-процессов на предприятии, которое может проводиться с той или иной степенью подробности. Сергей Рогинский говорит по этому поводу: “Интервал от начала работы до момента, когда окончательный выбор сделан, может объективно занимать до четырех месяцев. Если это приличное по размерам предприятие, то только его обследование, как правило, длится не меньше трех месяцев. Тендерное письмо при этом может содержать до полусотни страниц, в которых мы пытаемся не только сформулировать основные требования к системе, но и описать структуру компании и ее особенности”. Консультант просто переносит часть собственной работы по обследованию предприятия (обычно выполняемой на стадии внедрения) на этап проведения тендера. Возможность осуществления подобного маневра — фактор безусловно благоприятный: на стадии выбора иметь более детальную картину бизнеса компании крайне полезно. 4.Как учитывать технологии. Один из потенциально спорных моментов, касающихся постановки задач при выборе, состоит в том, целесообразно ли рассматривать технологические особенности решений. С одной стороны, известно, что выбор системы должен делаться бизнесом и для нужд бизнеса, а, следовательно, функционал программного обеспечения необходимо рассматривать исключительно с этой точки зрения. Понятно, что наиболее ключевые из них напрямую связаны с качеством сервиса, который будет в конечном итоге отражать адекватность решения бизнес-задач. Уже на первом этапе выбора, на котором решаются вопросы принципиальной годности систем, такие технологические аспекты, как используемый сервер баз данных или, например, наличие в системах поддержки CASE-технологии, обязательно должны приниматься во внимание. Кроме того, технологические акценты при выборе должны по идее играть тем большую роль, чем мощнее к моменту выбора комплексной системы управления оказывается накопленная инфраструктура автоматизации на предприятии и чем более акцентировано стремление организации интегрироваться в отраслевые проекты электронного бизнеса. Нацеленность тендерной процедуры на объективность и учет максимального числа возможных факторов вряд ли позволяет вовсе обойти вниманием технические вопросы. При традиционном порядке выбора системы — и множество описанных нами проектов прямо подтверждают данный факт — чисто технические вопросы очень редко ставятся в ряд критериев ранжирования корпоративных систем на предмет их оптимальности для автоматизации бизнес-процессов (хотя, надо признаться, бывают и исключения). Вопрос о том, должны ли технологические вопросы входить в список критериев, в соответствии с которыми выбирается корпоративная система, в свою очередь, связан с проблемой привлечения к тендерной процедуре технических специалистов. 5.Таблица анализа информационной системы № п/п Критерии Оцен-ка Текстовое пояснение Диапазон оценки: Если оценка не применима, следует указывать абсолютную величину или ограничиться пояснением Функция (возможность) отсутствует 1 Предполагается в следующей версии 2 Требует незначительных усилий по доработке 4 Реализована и работает в российских условиях (неруссифицирована) 5 Реализована и работает в российских условиях (руссифицирована) 1. Фирма - поставщик 1.1 Основные критерии 1.1.1 Количество лет в бизнесе 1.1.2 Количество лет в России 1.1.3 Представительство в России 1.1.4 Количество партнеров в России 1.1.5 Мультинациональность (представительства во многих странах) Итого по основным критериям 1.2 Внутренняя организация фирмы 1.2.1 Подразделение разработки и исследования 1.2.2 Подразделение продаж 1.2.3 Подразделение маркетинговых исследований 1.2.4 Каналы распространения 1.2.5 Подразделение внедрения продуктов 1.2.6 Подразделение сопровождения продуктов 1.2.7 Подразделение консультаций 1.2.8 Подразделение обучения Итого по внутренней организации 1.3 Организация бизнеса в России 1.3.1 Подразделение разработки и исследования 1.3.2 Подразделение продаж 1.3.3 Подразделение маркетинговых исследований 1.3.4 Каналы распространения 1.3.5 Подразделение внедрения продуктов 1.3.6 Подразделение сопровождения продуктов 1.3.7 Подразделение консультаций 1.3.8 Подразделение обучения 1.3.9 Количество специалистов, обеспечивающих сопровождение и консультации Итого по внутренней организации Итого по фирме-поставщику 2. Система 2.1 Общие критерии 2.1.1 Специализация для (указать отрасли промышленности) 2.1.2 Множественность балансовых единиц 2.1.3 Управление комплексной структурой предприятия 2.1.4 Интегрированность оперативного, управленческого и финансового учета 2.1.5 Гибкость при изменяющихся бизнес условиях 2.1.6 Полиотчетность, многовалютность 2.1.7 Экспорт и импорт данных и отчетов 2.1.8 Возможность создания прототипов форм, отчетов 2.1.9 Разработка версий под российский рынок Итого по общим критериям 2.2 Характеристики реализации 2.2.1 Максимальное количество одновременно работающих пользователей 2.2.2 Требования к сети и аппаратной платформе 2.2.3 Максимальное количество аналитических признаков на единицу учета 2.2.4 Максимальный диапазон хранимых сумм 2.2.5 Максимальный размер стандартного текстового поля 2.2.6 Максимальный размер мемориального (ссылочного) текстового поля 2.2.7 Технология клиент-сервер 2.2.8 Технология Intranet/Internet 2.2.9 Многоплатформенность (UNIX, AS/400, S 390, Windows NT) 2.2.10 NetWare 2.2.11 Использование промышленных СУБД (Oracle, Informix, Sybase и т.д.) 2.2.12 Масштабируемость (легкость расширения и сужения системы) 2.2.13 Эффективность работы при одновременном обслуживании более 100 пользователей 2.2.14 Эффективность работы при интенсивности прироста информации: 1000 документов и 100000 аналитических операций (проводок) в день 2.2.15 Наличие метаязыковых средств описания и настройки данных и процедур системы 2.2.16 Многоплатформенность клиентской части (Windows, DOS) 2.2.17 Наличие средств OLAP 2.2.18 Отсутствие перерывов в работе для обслуживания системы (архивирование, проверка целостности) Итого по характеристикам реализации 2.3 Функциональные требования 2.3.1 Управление финансами (корпорация, подразделения) 2.3.2 Управление основными средствами 2.3.3 Финансовое планирование и бюджетирование 2.3.4 Управление инвестициями 2.3.5 Управление закупками 2.3.6 Управление запасами (товародвижение) 2.3.7 Управление продажами 2.3.8 Маркетинг (поставщики, заказчики) 2.3.9 Управление затратами 2.3.10 Управление заработной платой 2.3.11 Управление персоналом 2.3.12 Управление проектами 2.3.13 Управление производством: дискретное и непрерывное 2.3.14 Управление цепочками поставок (поставщик-предприятие-заказчик) 2.3.15 Управление транспортом и перевозками 2.3.16 Планирование, в том числе с учетом ограничений 2.3.17 Управление оказанием услуг клиентам (заказы: интеграция с запасами, производством, НПЗ, транспортировкой) 2.3.18 Управление качеством 2.3.19 Наличие средств построения модели предприятия Итого по функциональности 3. Требования к базам данных 3.1 Степень внешней интеграции 3.1.1 Интеграция с другими приложениями для конечного пользователя 3.1.2 Интеграция с E-mail 3.1.3 Интеграция с Internet/Intranet 3.1.4 Интеграция с системой iMAN (указать уровень интеграции) 3.1.5 Интеграция с системами документооборота (Documentum, DOCS Open и т.д.) Итого по степени внешней интеграции 3.2 Степень внутренней интеграции 3.2.1 Формирование информации верхних уровней непосредственно из информации нижних уровней любого модуля 3.2.2 Детализация информации до источников любого нижнего уровня любого модуля любого филиала (drill down) 3.2.3 Настраиваемое изменение статуса подразделений (от статуса центра учета до балансовой единицы и обратно) 3.2.4 Настраиваемая функциональная увязка аналитических признаков нижних уровней с аналитическими показателями верхних уровней 3.2.5 Отсутствие необходимости повторного ввода данных Итого по степени внутренней интеграции 3.3 Управление данными 3.3.1 Разграничение полномочий пользователей по функциям 3.3.2 Разграничение доступа к данным 3.3.3 Разграничение по группам пользователей 3.3.4 Кодирование данных 3.3.5 Автоматическое обеспечение целостности данных 3.3.6 Отслеживание лимита по объему данных 3.3.7 Возможности автоматического архивирования данных 3.3.8 Резервное копирование данных 3.3.9 Восстановление данных 3.3.10 Возможности репликации данных 3.3.11 Возможности распределения приложений и баз данных 3.3.12 Оптимизация хранения данных 3.3.13 Наблюдение за использованием приложений 3.3.14 Наблюдение за использованием данных Итого по управлению данными Итого по базам данных 3.4 Простота в использовании 3.4.1 Возможность изменения интерфейса для каждого пользователя 3.4.2 Стандартизация клавиш и управляющих графических элементов по всем модулям 3.4.3 Стандартизация стиля экранных форм 3.4.4 Возможность массового ввода без использования «мыши» 3.4.5 Возможности формирования собственных меню, формы, отчета 3.4.6 Быстрота заполнения полей справочной информацией (эффективность заполнения lookup полей) Итого по простоте в использовании 3.5 Простота внедрения 3.5.1 Наличие встроенных средств построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм 3.5.2 Наличие фирменной методологии внедрения 3.5.3 Наличие библиотеки настроек (для российского бухгалтерского учета: стандартная отчетность, корреспонденция счетов, сторнирование, взаимозачеты и пр.) 3.5.4 Возможность быстрой перенастройки системы во время внедрения 4. Поддержка и сопровождение 4.1 Техническая поддержка 4.1.1 Простота связи с фирмой 4.1.2 Оперативность ответной реакции 4.1.3 Аккуратность ответа 4.1.4 Консультационные услуги 4.1.5 Локальная поддержка 4.1.6 Справочные услуги (по телефону) 4.1.7 Справочные услуги (online) 4.1.8 Информация о новостях 4.1.9 Гарантия 4.1.10 Сопровождение продукта 4.1.11 Обеспечение новыми версиями Итого по технической поддержке 4.2 Обучение 4.2.1 Обучение на рабочем месте 4.2.2 Обучение у поставщика средств 4.2.3 Самообучение 4.2.4 Обучение у третьих компаний 4.2.5 Руководство по инсталляции 4.2.6 Руководство пользователя 4.2.7 Сообщения об ошибках 4.2.8 Техническое руководство Итого по обучению Итого по поддержке и сопровождению 5. Требования со стороны бизнес-процессов 5.1 Управление финансами 5.1.1 Составление финансового плана на основании внесенных запланированных данных по доходам и расходам в аналитике по подразделениям 5.1.2 Планирование денежных потоков 5.1.3 Наличие системы банк-клиент. Возможность использования внешней системы банк-клиент 5.1.4 Определение временных рамок наличия свободных денежных средств / потребности в денежных средствах, как в рублевых, так и валютных 5.1.5 Возможности нормирования расходов в соответствии с составом затрат, сметой проектов и т.п. в аналитике по подразделениям 5.1.6 Наличие системы утверждения предварительно сформированных платежей 5.1.7 Возможность разбиения поставок товара и оплату на частичной основе 5.1.8 Разноска платежей (в т.ч. сформированных ранее) по мере подтверждения оплаты 5.1.9 Опция возврата платежа (как неверно перечисленного и т.п.) 5.1.10 Опция информирования всех заинтересованных лиц о внесенных изменениях в закрытых периодах 5.1.11 Формирование стандартных статистических отчетов по финансовой части Итого по финансовому отделу 5.2 Бюджетирование и планирование 5.2.1 Возможность ввода плановых показателей и анализа их выполнения 5.2.2 Возможность корректировки плановых показателей в течение отчетного периода 5.2.3 Возможность формирования планового задания в отдельности по каждому подразделению и анализ выполнения 5.2.4 Бюджетирование расходов по центрам затрат, проектам и подразделениям / центрам ответственности 5.2.5 Автоматическое формирование Российского и Западного балансов и приложений к балансу 5.2.6 Стандартный анализ финансовых показателей на основании данных балансового отчета 5.2.7 Формирование необходимых расчетных форм на основании данных баланса и приложений к нему 5.2.8 Возможность организации интерфейса с внешними программными средствами с целью проведения анализа и дополнительных расчетов (специальные программы, Excel, Access, Power Builder) 5.2.9 Возможность ведения учета на удаленных местах (возможность импорта с носителей, модемная связь, удаленный автономный терминал и т.п.) 5.2.10 Возможность планирования платежей будущих периодов, в т.ч. на основании статистических данных прошлых периодов 5.2.11 Возможность оперативного доступа к данным за предыдущие периоды (какова глубина доступа: 1 год, 2 года …) 5.2.12 Консолидация данных (плановых, бюджетных, фактических) на уровне центров затрат, проектам и подразделениям / центрам ответственности 5.2.13 Контроль проектов (открытие, приостановление, закрытие, перераспределение) – связано с работой секций, важна индикация текущего состояния 5.2.14 Возможность настройки выходных форм аналитических отчетов, возможность изменения стандартных 5.2.15 Однократный ввод валютных курсов и возможность использования таблицы валютных курсов внешними средствами обработки данных Итого по бюджетированию и планированию 5.3 Бухгалтерия 5.3.1 Средства детального анализа баланса по подразделениям 5.3.2 Наличие буфера накопления проводок для ввода их в Главную Книгу 5.3.3 Возможность получать отчеты и делать корректировки для проводок, находящихся в буфере (если он есть) 5.4 Учет расчетов с рабочими и служащими 5.4.1 Доступ (интеграция) к данным отдела кадров, приказам по персоналу: зачисление, увольнение, перевод, изменение в штатном расписании 5.4.2 Интеграция с модулем «счета к оплате» – для регистрации задолженностей по налогам и удержаниям 5.4.3 Ввод и авторизация табелей учета рабочего времени в комплексах/секциях. Проверка табелей и их авторизация в режиме on-line 5.4.4 Запросы по расчетам (начисления, удержания, авансы, расчет пенсии, детские компенсации) с персоналом в режиме on-line 5.4.5 Вся информация по начислениям в фонды социального и медицинского страхования доступна из модуля учета расчетов по зарплате 5.4.6 Возможность ввода графика учета рабочего времени – ФИО, дата, время начала и время окончания 5.4.7 Возможность регистрации нарядов на сдельную работу, расчет зарплаты сдельщиков 5.4.8 Возможность регистрации нарядов на сдельную работу в местах их возникновения, расчет зарплаты сдельщиков 5.4.9 Ведение картотеки депонированной зарплаты 5.4.10 Возможность организации расчета заработной платы с учетом положений УМПО по оплате 5.4.11 Формирование платежных ведомостей на выплату зарплаты через кассу 5.4.12 Перечисление зарплаты для выплаты через Сбербанк (пластиковые карты) 5.4.13 Организация перечисления удержаний из зарплаты за коммунальные услуги, Госстрах, кредит, ссуды, алименты, питание в столовых УМПО, покупку товаров УМПО в счет зарплаты и др. 5.4.14 Формирование финансового свода по подразделениям, заводам 5.4.15 Интеграция с модулем «Главная книга» 5.4.16 Возможность ведения персонифицированного учета согласно требований Пенсионного фонда 5.4.17 Возможность ведения картотеки совокупного годового дохода по работающим согласно требований ГНИ Итого по учету с рабочими и служащими 5.5 Учет банковских и кассовых операций 5.5.1 Ввод графика платежей на месяц вперед, планирование платежей 5.5.2 Возможности контроля и планирование остатка на счетах 5.5.3 Средства генерации платежных документов: платежных поручений, расходных кассовых документов, заявлений на перевод (в валюте) 5.5.4 Регистрация поступающих платежных документов (платежных поручений) 5.5.5 Генерация отчета о движении денежных средств по форме № 4 5.5.6 Расчеты с подотчетными лицами (регистрация авансовых отчетов). Контроль срока задолженности подотчетного лица 5.5.7 Ведение паспортов сделки, регистрация таможенных деклараций 5.5.8 Расчеты (регистрация) в кассе приходных и расходных ордеров 5.5.9 Возможность формирования платежных поручений, счетов-фактур по расчетам с потребителями на базе данных приказов на отгрузку продукции отделом сбыта 5.5.10 Возможность формирования взаимозачетов 5.5.11 Возможность формирования книги покупок и продаж согласно требований ГНИ Итого по учету банковских и кассовых операций 5.6 Учет основных средств, МБП, материалов 5.6.1 Возможность регистрации всей необходимой информации по основному средству в момент приобретения – инв. номер, коды, суммы как в соответствии с российским учетным законодательством, так и в соответствии с GAAP 5.6.2 Наличие функций обработки запросов по основным средствам в режиме on-line 5.6.3 Возможность печати инвентарных ярлыков с цифровым и штрих кодовым номерами (для нужд инвентаризации) 5.6.4 Движение, оценка и начисление амортизации – в соответствии с российским законодательством и GAAP 5.6.5 Возможность регистрации информации о движении основных средств и произведенных ремонтах и модернизациях 5.6.6 Возможность выверки между учетными данными (первоначальная стоимость, накопленный износ) по российским данным и по GAAP 5.6.7 Возможность переоценки основных средств в соответствии с российским законодательством 5.6.8 Использование повышающих -понижающих коэффициентов при расчете амортизации 5.6.9 Ввод накопленной амортизации для старых основных средств 5.6.10 Возможность текстового расчета амортизации 5.6.11 Возможность привязки основных средств к разным категориям, для которых определены разные способы расчета амортизации 5.6.12 Возможность приостанавливать амортизацию на указанный период 5.6.13 Расчет амортизации в режиме пакетного ввода 5.6.14 Перерасчет амортизации в закрытых периодах 5.6.15 Возможность перевода основных средств из одной категории в другую (например, в МБП) 5.6.16 Привязка материально-ответственных лиц. Интеграция с модулем Персонала 5.6.17 Привязка к центрам затрат. Интеграция с модулем управления затратами 5.6.18 Учет драгметаллов а) в материалах б) в основных средствах Итого по учету основных средств 5.7 Учет и планирование производства 5.7.1 Возможность регистрации и авторизации заказов на производство, возможность автоматического создания номенклатурной единицы для заказа по спецификации. Каждый заказ клиента отличается как видами готовой продукции предприятия, так и видами и марками материалов, из которых она должна быть изготовлена, дополнительными технологическими особенностями 5.7.2 Возможность изменения существующего заказа в режиме он-лайн 5.7.3 Обеспечение связи между заказом и производственным процессом. По каждому заказу клиента в системе должна быть возможность определения маршрута обработки (участки, станки/механизмы, время), а также необходимых материалов (закупаемых или производимых). Доступность информации по запасам и незавершенному производству для удовлетворения заказа. 5.7.4 Возможность оперативной замены номенклатурной единицы на альтернативную 5.7.5 Наличие шаблонных форм ввода заказа 5.7.6 Возможность работы в смешанных системах планирования 5.7.7 Учет побочных и попутных продуктов. Управление формулами изделий 5.7.8 Возможность управления смешанными процессами. Система должна поддерживать учет производительности и использования ресурсов (в т.ч. временных) в разрезе станков/механизмов с группировкой по участкам производства (с возможностью учета как нормативных, так и фактических величин) 5.7.9 Возможность привязки материалов к станкам и участкам (многие ко многим), с указанием вида операции, выполняемой на данном станке с материалом. Возможность определения норм расхода материалов, нормативного времени обработки материалов в разрезе станков и операций 5.7.10 В системе должны быть функции для определения норм расхода материалов, нормативного времени обработки материалов в разрезе станков/механизмов и операций 5.7.11 Система должна поддерживать учет рабочего времени как в машино-часах, так и в человеко-часах 5.7.12 В системе должна быть возможность учета по каждому материалу (как нормативные, так и фактические данные) с использованием различных единиц (кг., тонны, шт.) с возможностью пересчета из одной единицы в другую 5.7.13 Планирование с учетом «наличное для обязательств» и «возможное для обязательств» 5.7.14 Возможность учета следующей технологической информации по клиентским заказам по каждому участку: • заказ • участок • оборудование • материалы • отходы • время начала выполнения • время окончания выполнения • дополнительные технологические сведения • мастер, отвечающий за выполнение заказа • рабочий, отвечающий за выполнение операций по заказу 5.7.15 В системе должна быть возможность учета обработки заказа на одном станке / механизме несколькими сменами рабочих (по каждой смене и заказу должны учитываться затраты рабочего и машинного времени, использованные материалы, объем незавершенного производства, объем выпуска продукции 5.7.16 Связь заказа с транспортировкой, упаковкой, видом крепления 5.7.17 Ведение книги выполнения заказов 5.7.18 При подготовке ежемесячного плана производства система должна как обеспечивать информацию по планируемым заказам, так и по запасам на складе готовой продукции и незавершенному производству 5.7.19 Система должна поддерживать подготовку, корректировку и контроль выполнения ежемесячных планов производства в разрезе клиентских заказов 5.7.20 В системе должны быть обеспечены возможности планирования загрузки оборудования на основе информации по обрабатываемым заказам и заказам, ожидающим обработки. При этом система должна обеспечивать возможность расстановки приоритетов заказов с учетом правила, что исполнение заказа на станке не может быть прервано для исполнения другого заказа 5.7.21 Система должна поддерживать процесс маршрутизации заказа с использованием классификаторов оборудования, операций, материалов и сырья, промежуточных продуктов. При этом плановик должен иметь возможность оценки различных маршрутов производства (по ресурсам) и эффективности 5.7.22 Система должна автоматически рассчитывать затраты на изготовление заказа на основе сформированного маршрута (с учетом норм брака, времени на переналадку оборудования, дополнительного времени рабочих и т.д.) 5.7.23 В системе должен быть автоматизирован процесс получения маршрутных и технологических карт (в разрезе станков, заказов, материалов) 5.7.24 Система должна контролировать отклонения нормативных затрат на выполнение заказа, которые отличаются от плановых калькуляций по предварительному заказу на определенную величину (к примеру, 1%) 5.7.25 В системе должны учитываться затраты машинного и рабочего времени (в том числе времени на переналадку оборудования), материалов на выполнение заказа – позаказно, посменно, в разрезе участков и оборудования с указанием рабочих, выполнивших заказ 5.7.26 В системе должен учитываться выпуск готовой продукции, незавершенное производство – позаказно, посменно, в разрезе участков и оборудования с указанием рабочих, выполнивших заказ 5.7.27 Информация о фактических затратах (26,27) должна заводится в систему в местах возникновения и быть доступной другим 5.7.28 В системе должны быть средства для формирования оперативной информации по производству: • выполняемые в текущий момент заказы (срок выполнения, % выполнения) по оборудованию и участкам • фактические и планируемые переменные затраты на производство по заказам (сравнение фактических затрат с нормативными затратами и затратами, определенными при подготовке предварительного заказа) • фактический и планируемый выпуск по заказам в разрезе участков, оборудования, рабочих, смен • фактические временные затраты / плановые временные затраты на выпуск продукции в разрезе заказов, участков, оборудования, рабочих • загрузка оборудования (заказы, обрабатываемые в настоящий момент, заказы, ожидающие выполнения) 5.7.29 В системе должны быть средства для формирования ежемесячных заявок на закупку на основании плана производства 5.7.30 В системе должны быть средства для формирования ежемесячных заявок на закупку на основании плана производства с учетом истечения срока годности комплектующих и агрегатов, имеющих ограниченный срок годности (подшипники, резина и т.д.) , а также допустимые замены при использовании остатков 5.7.31 Система должна поддерживать выполнения функции контроля годового и квартальных планов производства (на основе сравнения агрегированных плановых показателей по выпуску различных видов продукции и фактических данных) 5.7.32 Расчет сводных норм на изделие 5.7.33 Расчет спецификации материалов по цеху в разрезе изделий 5.7.34 Учет и планирование отходов по материалам 5.7.35 Ведение ведомости оснащения 5.7.36 Система учета и планирования оснащения 5.7.37 Наличие ИПС (информационно-поисковая система инструмента) 5.7.38 Создание сопроводительной карты при запуске деталей, сборочных единиц и ввод отметок о перемещении по технологическому маршруту в интерактивном режиме.Отметка о перемещении должна содержать дату, время проведения операции, подтверждение сдатчика и получателя. 5.7.39 Сигнализация о нарушениях в учетных документах, таких как появление минусовых остатков 5.7.40 Возможность ведения учета как партиям, так и в накопительном режиме 5.7.41 Возможность перемещения деталей, сборочных единиц с отклонением от технологического маршрута (со скачком по маршруту, обратно и т.д.) 5.7.42 Наличие учетной операции разделения : одна заготовка – несколько деталей 5.7.43 Возможность ‘разметки’ рассчитанных потребностей по источникам возникновения: исходный заказ, дата изготовления заказа, цех-получатель 5.7.44 Учет активности спецификации и маршрута. 5.7.45 Возможность задания приоритетов и ограничений при гашении потребностей остатками 5.7.46 Наличие алгоритма обработки отрицательных остатков 5.7.47 Возможность трассировки расчета потребностей до товарных заказов 5.7.48 Возможность оперативного перепланирования по изменениям. 5.7.49 Возможность задания альтернативных спецификаций на изделия и узлы и альтернативных маршрутов изготовления 5.7.50 Возможность учета проведения изменений по всем нормативным базам данных на определенное количество комплектов изделия, на определенный интервал времени, с использованием задела 5.7.51 Возможность проведения изменений по всей нормативной базе данных на прогнозируемые изменения 5.7.52 Фиксация нормативных данных по изделиям на дату отгрузки, ее архивация и хранение в течение 20 лет 5.7.53 Возможность разграниченного доступа к нормативной информации по изделиям: планируемым и не планируемым 5.7.54 Ведение журнала регистраций изменений по всем нормативным и оперативным данным с указанием автора изменений и основания для его проведения в течении всего периода существования изделий Итого по учету производства 5.8 Сводная отчетность и налогообложение 5.8.1 Возможность регистрации балансов дочерних компаний в отдельные базы данных (раздельные «Главные Книги»). Консолидация балансов. 5.8.2 Возможность генерации финальных финансовых отчетов для публикации и предоставления в ГНИ на основе проводок 5.8.3 Возможность переоценки счетов расчетов в иностранных валютах (централизованно) Итого по сводной отчетности и налогообложению 5.9 Инвентаризация, контроль и сохранность имущества 5.9.1 Ведение книги приказов на проведение инвентаризации, генерация (печать) приказов Итого по инвентаризации, контролю и сохранности имущества 5.10 Ценообразование 5.10.1 Возможность изменения торговых надбавок на товары с их автоматическим пересчетом 5.10.2 Автоматический пересчет товарных запасов, учитываемых в валюте (USD, DM), в рубли 5.10.3 Автоматический расчет отпускных / розничных цен от контрактной с использованием таких параметров как торговая надбавка, НДС, таможенная очистка 5.10.4 Ведение истории закупочных цен (необходимы данные по первоначальным контрактным ценам) 5.10.5 Доступ к историческим данным по ценам, в т.ч. с возможностью сортировки условий выборки 5.10.6 Планирование и установка скидок на определенный период и на определенные группы изделий 5.10.7 Расчет статистических ценовых показателей Итого по ценообразованию 5.11 Управление товародвижением 5.11.1 Ведение справочника номенклатуры 5.11.2 Поступление и приходование на склад 5.11.3 Формирование приходных накладных 5.11.4 Анализ данных о поставщиках 5.11.5 Создание заказов на поставку и контроль за их выполнением 5.11.6 Ведение истории документа (заказа, договора, контракта) 5.11.7 Работа со многими, в т.ч. удаленными складами 5.11.8 Аналитические отчеты 5.11.9 Формирование инвентаризационной описи («плюс» дополнительная настройка выводимых полей, таких как, первоначальные контрактные цены, текущие цены, группы, партии, артикулы и т.п.) 5.11.10 Формирование необходимых отчетов по товарным запасам и товародвижению («плюс» дополнительная настройка выводимых полей, таких как, первоначальные контрактные цены, текущие розничные цены, товарные группы, артикулы и т.п.) 5.11.11 Опция внутреннего перемещения товара, а также перемещения товара внутри корпорации / холдинга 5.11.12 Списание товаров 5.11.13 Учет в количественном выражении, учет в суммовом выражении и в различных валютах 5.11.14 Анализ товарооборота: • по подразделениям, в т.ч. внутри корпорации / холдинга • по товарным группам и подгруппам • за период и нарастающим итогом • планирование на будущие периоды на основании результатов продаж 5.11.15 Анализ товарных запасов: • по подразделениям, внутри корпорации / холдинга • по товарным группам и подгруппам • по суммам и дням • товары с длительной реализацией 5.11.16 Аналитика по поступлениям: • по подразделениям, в т.ч. внутри корпорации / холдинга • суммовой и по потерям в товарообороте • графическое представление • расчет оплаты поставщикам и таможне исходя из фактической выручки за день 5.11.17 Учет запасов по поставщику в аналитике по секциям, складам, валютам 5.11.18 Стандартная опция сортировки наименований товара, как по артикулу, так и по коду товара 5.11.19 Формирование центров прибыли по товарным группам 5.11.20 Установление кодировочных связей для совмещения одного плана товарных групп с другими внешними 5.11.21 Глубина разбивки по товарным группам, подгруппам и т.д. (сколько уровней) 5.11.22 Планирование закупок по группам товаров, по филиалам, по ценам закупки и реализации и т.п. 5.12 Маркетинг / Поставщики 5.12.1 Наличие модуля маркетинга для проведения маркетинговых исследований (с учетом торговых организаций) 5.12.2 Ведение базы данных поставщиков 5.12.3 Выход в интернет, e-mail и т.д. 5.12.4 Возможность контроля поставщиков на дублирование (по названию, по коду в налоговой инспекции и т.п.) 5.12.5 Возможность группировки поставщиков / покупателей, имеющих один код в налоговой инспекции, одно название и т.п. 5.12.6 Занесение данных по условиям оплаты отдельно для каждого из поставщиков 5.12.7 Многовалютность расчетов с поставщиками (возможность использования множества валют для расчетов с одним поставщиком) 5.12.8 Возможность автоматического расчета сумм платежей поставщикам исходя из условий оплаты 5.12.9 Контроль задолженности по поставщику с механизмом предупреждения 5.12.10 Занесение условий поставок по контрактам (сроки, номенклатура, количество, цены и т.п.) 5.12.11 Возможность расчета штрафных санкций за несоблюдение условий поставок, за задержку оплаты, анализ сроков оплаты и потерь 5.12.12 «История» поставщика и характеристики сотрудничества с ним 5.12.13 Информация о продажах по поставщикам (день продаж, период продаж, сумма, количество, товар, артикулы, поставщики товара, товарные группы / подгруппы и т.п.) Итого по маркетингу 6 Стоимость и сроки внедрения 6.1 Стоимость 1 вариант ($) 6.1.1 Цена лицензии из расчета 300 пользователей (конфигурация определяется разделом требований со стороны бизнес – процессов): • на каждого именованного пользователя • на каждого одновременно работающего пользователя • на каждое рабочее место (компьютер) 6.1.2 Итоговая стоимость лицензии 6.1.3 Стоимость технической настройки по результатам проектирования 6.1.4 Стоимость необходимых дополнительных программных продуктов 6.1.5 Стоимость обучения 6.1.6 Стоимость годового сопровождения 6.1.7 Средняя стоимость годовой технической поддержки 6.1.8 Ориентировочная стоимость аппаратного сервера (300 пользователей) Итого по стоимости 1 вариант 6.2 Стоимость 2 вариант ($) 6.2.1 Цена лицензии из расчета 150 пользователей (та же конфигурация за исключением товародвижения и логистики): • на каждого именованного пользователя • на каждого одновременно работающего пользователя • на каждое рабочее место (компьютер) 6.2.2 Итоговая стоимость лицензии 6.2.3 Стоимость технической настройки по результатам проектирования 6.2.4 Дополнительные затраты на интеграцию с модулями логистики 6.2.5 Стоимость необходимых дополнительных программных продуктов 6.2.6 Стоимость обучения 6.2.7 Стоимость годового сопровождения 6.2.8 Средняя стоимость годовой технической поддержки 6.2.9 Ориентировочная стоимость аппаратного сервера (150 пользователей с возможностью расширения) Итого по стоимости 2 вариант 6.3 Стоимость 3 вариант ($) 6.3.1 Цена лицензии из расчета 100 пользователей (та же конфигурация только для товародвижения и логистики): • на каждого именованного пользователя • на каждого одновременно работающего пользователя • на каждое рабочее место (компьютер) 6.3.2 Итоговая стоимость лицензии 6.3.3 Стоимость технической настройки по результатам проектирования 6.3.4 Дополнительные затраты на интеграцию с модулями логистики 6.3.5 Стоимость необходимых дополнительных программных продуктов 6.3.6 Стоимость обучения 6.3.7 Стоимость годового сопровождения 6.3.8 Средняя стоимость годовой технической поддержки 6.3.9 Ориентировочная стоимость аппаратного сервера (200 пользователей с возможностью расширения) Итого по стоимости 3 вариант 6.4 Сроки внедрения 6.4.1 Ориентировочные сроки внедрения, 1 вариант 6.4.2 Ориентировочные сроки внедрения, 2 вариант 6.4.3 Ориентировочные сроки внедрения, 3 вариант Итого по срокам внедрения Технические требования к комплексным системам автоматизации предприятий 1. Требования к фирме-поставщику 1.1 Фирма-поставщик должна иметь большой международный опыт работы с промышленными предприятиями. Иметь успешные внедрения в производственной сфере, а также иметь успешные внедрения на российских предприятиях. 1.2 Фирма-поставщик должна иметь в России квалифицированные кадры для разработки и модернизации программного обеспечения, внедрения, сопровождения, технической поддержки и обучения. 2. Общие требования к системе 2.1 Система должна обеспечивать поддержку управленческих функций как в корпоративных масштабах (когда централизованно осуществляется финансовое и производственное планирование, учет и контроль), так и на решение задач в отдельно взятых производственных единицах, которые могут действовать или как полностью самостоятельные подразделения с автономным контуром управления, или составные элементы сложной холдинговой системы. 2.2 Система должна иметь возможность интеграции с функционирующими на предприятиях автоматизированными комплексами и задачами. 2.3 Иметь инструмент для разработки приложений, учитывающих особенности российского рынка. 3. Требования к техническим характеристикам 3.1 Программное обеспечение должно обладать открытой архитектурой «клиент-сервер» и иметь средства взаимодействия с другими программными продуктами. 3.2 Программное обеспечение должна иметь возможность работы в среде Intranet/Internet. 3.3 Программное обеспечение должно иметь многоплатформенную структуру, поддерживать различные операционные системы (Unix, NetWare,Windows NT), и работать с различными базами данных (Oracle, Informix, MS SQL Server, DB2 и другими). При этом должна быть предусмотрена возможность одновременной работы с различными базами данных, а также доступ к базе данных из любых приложений системы. 3.4 Система должна обладать свойством масштабируемости (легкостью расширения и сужения системы), обеспечивать работу пользователей через Интернет и иметь метаязыковые средства описания и настройки данных и процедур системы. Формирование информации верхних уровней должно происходить непосредственно из информации нижних уровней любого модуля, детализация информации должна быть возможна до источников любого нижнего уровня, любого модуля и любого филиала. 3.5 В системе должна быть предусмотрена возможность распределения приложений и баз данных, возможность резервного копирования и репликации данных. Обеспечение целостности данных должно выполняться автоматически. 3.6 Средства безопасности, используемые в системе, должны обеспечивать минимизацию риска некорректного использования или злоупотребления системой, а также разграничение полномочий пользователей по функциям. Доступ должен быть ограничен системой идентификации пользователя и пароля. В системе должен поддерживаться график аудита, обеспечивающий мониторинг каждого вхождения или попыток злоупотребления системой. 3.7 Программное обеспечение должно обеспечивать простоту внедрения и конфигурации информационной системы с помощью использования встроенных средств построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм. 4 Требования к функциональности Программное обеспечение информационной системы должно поддерживать выполнение полного комплекса интегрированных функций системы управления предприятием: 4.1 Управление финансовой и бюджетной деятельностью предприятия (составление финансового плана, планирование денежных потоков, бюджетирование расходов по центрам затрат, проектам и подразделениям, центрам ответственности, автоматическое формирование Российского и Западного балансов и приложений к балансу и др.); 4.2 Бухгалтерский учет и контролинг (ведение и подготовка выходных документов в соответствии с требованиями российского учета, детальный анализ баланса по подразделениям, буфер накопления проводок для ввода их в Главную Книгу с возможностью корректировки проводок в буфере, работа с «красным сторно», регистрация балансов дочерних компаний в отдельные базы данных (раздельные Главные Книги), консолидация балансов и др.); 4.3 Управление сбытом, снабжением и складами предприятия, планирование и учет товарно-материальных потоков предприятия (поступление и приходование на склад, со склада в цеховую кладовую, создание заказов на поставку и контроль за их выполнением, анализ товарооборота по подразделениям, товарным группам, учет запасов по изделиям в аналитике по секциям, складам, валютам, формирование отчетов по товарным запасам и товародвижению и др.); 4.4 Управление производством (дискретное и непрерывное производство различных типов – единичное, серийное, массовое, расчет нормативной и фактической себестоимости продукции, оперативное управление производственным процессом, моделирование производственных планов, создание и отслеживание выполнения планов производства и закупок, учет затрат машинного и рабочего времени, материалов на выполнение заказа – показано посменно в разрезе участков и оборудования и др.) и другие функции; 4.5 Планирование производственно-хозяйственной деятельности предприятия с учетом ограничений и приоритетов; 4.6 Управление инвестиционными проектами и капитальным строительством; 4.7 Управление транспортными задачами; 4.8 Управление сервисным обслуживанием и ремонтом оборудования; 4.9 Управление качеством продукции (соответствие стандарту качества ISO-9000). 5 Требования к базам данных 5.1 Система должна обеспечивать целостность и непротиворечивость данных и возможность распределенной обработки с использованием современных коммуникационных технологий (Интернет, e-mail). 5.2 Система должна обеспечивать разграничение доступа пользователей к данным и функциям системы. 5.3 Система должна обеспечивать архивирование, резервное копирование и восстановление данных. 5.4 Информационная модель Базы данных должна быть прозрачной и допускать разработку дополнительных приложений. 6 Требования к пользовательскому интерфейсу 6.1 Система должна иметь как алфавитно-цифровой, так и графический интерфейс. И иметь возможность оптимизации настроек для конкретного рабочего места. 7 Требования, предъявляемые на этапе внедрения 7.1 Система должна иметь встроенные средства построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм. 7.2 Система должна иметь адаптированную к условиям российских предприятий методологию внедрения. 7.3 Система должна обеспечивать возможность быстрой перенастройки во время внедрения. 8 Требования к поддержке, сопровождению и обучению 8.1 Фирма-поставщик должна обеспечивать поддержку и сопровождение системы и иметь базу для обучения специалистов заказчика. Лекция 6. Организация и реорганизация бизнес-процессов как подготовительный этап внедрения управленческой информационной системы. Понятие бизнес-процесса. Инструментарий и методология описания бизнес-процессов 1 Задачи реинжиниринга информационно-управляющих систем Предприятие представляет собой сложную систему, изменяющуюся во времени. Известно, что сложные вещи проще понимать, если они тем или иным образом зрительно представлены, а не только описаны вербально. Формальным способом визуализации какой-либо системы является построение моделей. Следует отметить, что модель, являясь отражением объективной реальности, не может быть адекватна моделируемой сущности и является всего лишь более или менее верным представлением этой сущности. Наиболее известную модель бизнеса – иерархическую структуру компании, - авторы считают недостаточной для проведения изменений компании и формулируют необходимость моделей, показывающих компанию в контексте ее клиентов, поставщиков, партнеров, т.е. в разрезе бизнес - процессов. С начала 90-х годов большое развитие получает теория М.Хаммера, обобщающая новые принципы организации современного производства на основе реинжиниринга бизнес-процессов [61, 166, 185, 268]. Необходимость реинжиниринга связывается с высокой динамичностью современного производства. Например, для Уфимского моторостроительного объединения становится нормой ежегодный прирост объемов производства 23-25%. Непрерывные и довольно существенные изменения в технологиях, рынках сбыта и потребностях клиентов стали обычным явлением, и производители, стремясь сохранить свою конкурентоспособность, вынуждены непрерывно перестраивать стратегию и тактику управления производством. В результате перепроектирование бизнес-процессов превращается в практику повседневной жизни предприятий, а инерционность многоуровневых систем управления становится тормозом на пути к их выживанию. Решение проблемы - в смене основных принципов организации производства и переходе к ориентации не на отдельные функции, а на процессы. Реинжиниринг бизнес-процессов ( BPR – business process reengineering) – фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов, имеющее целью резко улучшить их выполнение с точки зрения, качества и скорости обслуживания. Анализ различных подходов к процессам реинжиниринга показывает, что в основе процесса реинжиниринга лежит моделирование бизнес–процессов, при этом главной его составляющей является моделирование информационных процессов. Понятие реинжиниринга бзнес-процессов охватывает все материальные, финансовые и информационные потоки во взаимодействии. При этом отмечается, что реинжиниринг бизнес - процессов нельзя смешивать с решением таких задач, как автоматизация процессов обработки информации, реинжиниринг программного обеспечения, реорганизация организационной структуры, и др., которые могут решаться самостоятельно и независимо друг от друга. Вместе с тем предполагается их обязательное комплексное решение при реинжиниринге деловых процессов. По своей сути реинжиниринг есть развитие системы на основе знаний. Можно отметить следующие основные направления, составляющие основу методологии реинжиниринга: обеспечить ускорение информационных потоков, связывающих участников бизнес-процессов и улучшить синхронизацию одновременно выполняемых деловых процессов. Можно отметить следующие основные направления, составляющие основу методологии реинжиниринга: обеспечить ускорение информационных потоков, связывающих участников бизнес-процессов и улучшить синхронизацию одновременно выполняемых деловых процессов. Сущность реинжиниринга наглядно демонстрируется следующим примером. Несколько рабочих процедур объединяются в одну. Для перепроектированных процессов наиболее характерно отсутствие технологии «сборочного инструмента», в рамках которой на каждом рабочем месте выполняются простые задания, или рабочие процедуры. Выполнявшиеся различными сотрудниками, теперь они интегрируются в одну – происходит горизонтальное сжатие процесса. Если не удается привести все шаги процесса к одной работе, то создается команда, отвечающая за данный процесс. Наличие в команде нескольких человек неизбежно приводит к некоторым задержкам и ошибкам, возникающим при передаче работы между членами команды. Однако потери здесь значительно меньше, чем при традиционной организации работ, когда исполнители подчиняются различным подразделениям компании, располагающимся, возможно, на различных территориях. Кроме того, при традиционной организации трудно, а иногда и невозможно определить ответственного за быстрое и качественное выполнение работы. По имеющимся оценкам, горизонтальное сжатие ускоряет выполнение процесса примерно в 10 раз. 2.Понятие бизнес-процесса Термин «бизнес-процесс» определяется как множество внутренних шагов (видов) деятельности, начинающихся с одного или более входов и заканчивающихся созданием продукции, необходимой клиенту. При этом отмечается, что при традиционной структуре внимание фокусируется на заданиях, работах, людях, на структурах, но не на процессах. Но если и определяются конкретные процессы, то непростой задачей является объединение отдельных процессов в бизнес-процессы. Понятие «бизнес-процесс», прежде всего, включает в себя идею некоего процесса. Процесс происходит с участием определенного ресурса, и этот ресурс выступает как объект, на который направлен этот процесс. Т.е. процесс – некое действие над ресурсом. Данный процесс является элементом жизненного цикла ресурса, на который он направлен. Таким образом, разработав классификацию всех ресурсов предприятия и определив все процессы их жизненного цикла, можно определить всю совокупность производственных процессов предприятия. Здесь мы подошли к определению понятия «бизнес-процесс». В нашем понимании бизнес-процесс можно представить в виде замкнутого контура управления. Иными словами бизнес-процесс – это система, состоящая из объекта управления и управляющих функций над ним. Рассмотрим пример. Пусть у нас есть стол как ресурс. С этим столом у нас могут происходить определенные процессы, как-то транспортировка, покупка, продажа и др. Объединение конкретного процесса с ресурсом «стол» даст нам объект управления, например, «Транспортировка стола». Итак, у нас есть объект управления «Транспортировка стола» и контур управления над этим объектом, т.е. функции управления объектом, объединенные в замкнутый контур. Тем самым мы получили бизнес-процесс «Транспортировка стола». Данный бизнес-процесс, при описании технологии его работы, разбивается на функции, составляющие контур управления, и на функцию, которая непосредственно показывает исполнение данного бизнес-процесса. Стол мы можем разбить на составляющие, т.е. на такие элементы как ножки, столешница, крепежные винты и др. При моделировании деятельности, связанной со столом, мы оперируем понятием «стол», до тех пор, пока нас это устраивает. Если целесообразно выделить процессы, происходящие с составляющими стола, то рассматриваются отдельные контуры управления над ними. Предлагается следующая структура бизнес-процесса: • бизнес – функции – деятельность одного исполнителя по решению задачи бизнес – процесса • бизнес – операция – отдельная операция бизнес – функции, описывающая деятельность конкретного должностного лица над конкретным информационным объектом (документом, сущностью, записью в БД и т.д.) • бизнес правила, которые вводят ограничение на исполнение бизнес – процесса. Построение многоуровневой модели бизнес - процесса включает в себя организационно-штатную структуру предприятия, собственно модель бизнес – процесса, пронизывающего предприятие по горизонтали, а также данные о ресурсах различного вида. 3.Реализация процесса реинжиниринга в виде системного проекта Сложившаяся практика показывает нам, сколь трудоемки существующие методики представления всей совокупности бизнес-процессов предприятия в формализованном виде – в виде моделей. Приходится затрачивать значительные кадровые и временные ресурсы, чтобы получить полное описание деятельности предприятия. И, зачастую, результат далек от ожиданий. Отчеты по обследованиям годами лежат на полках, не принося никакой реальной пользы и не окупая вложенных затрат. Так стоит ли затрачивать огромную массу усилий, времени и средств, чтобы, в конце концов, остаться ни с чем? Чтобы ответить на этот вопрос, нужно четко представлять себе конечную цель моделирования. Если нужен просто отчет по обследованию, то это одно. Если нужен реальный инструмент, отражающий в формализованном виде текущую ситуацию на предприятии и позволяющий вносить коррективы в модели процессов деятельности предприятия, причем таким образом, чтобы это было понятно рядовым работникам предприятия – это другое. Результаты моделирования должны быть востребованы персоналом предприятия, т.е. модели должны все время поддерживаться в актуальном состоянии. Консультанты работают и уходят, а работникам приходится работать дальше на предприятии, поэтому результаты работы должны быть понятны персоналу, должны быть осознаны необходимость и важность этой работы, и, наконец, результаты работы должны стать инструментом регулярного менеджмента для персонала. Здесь еще присутствует один существенный момент. Вновь принятому на работу сотруднику достаточно лишь уметь читать язык формализованного описания процессов деятельности предприятия. Наглядное графическое представление послужит гораздо лучше любой должностной инструкции. С помощью модели новый сотрудник гораздо эффективнее усвоит круг своих должностных функций, связи административного и функционального подчинения и осознает свое место в едином социальном организме предприятия. Реинжиниринг ИУС, основанных на компьютерных технологиях, предполагает определенную культуру проектирования. Так по методологии SADT предполагается разработка функциональной (ФМ), информационной (ИМ) и динамической (ДМ) моделей, составляющих основу системного проекта информационно-управляющей системы (СП ИУС). Далее реализация СП ИУС может быть осуществлена по CASE технологии либо по технологии обычного с применением алгоритмических языков и программирования языков СУБД, либо по технологии экспертных систем. Процесс реинжиниринга существующих ИУС с применением системного проектирования позволяет проявить и формализовать основные интеллектуальные функции специалистов, работающих в информационной среде системы. Как отмечается в [166], реинжиниринг ставит перед собой цель – превратить искусство проектирования и управления компанией в инженерную дисциплину, для чего необходимо построить адекватные, понятные модели компаний (предприятия) и дать возможность именно менеджерам, а не системным программистам, анализировать последствия изменений этих моделей. Системный проект информационно-управляющей системы должен быть реализован в едином информационном пространстве, что обеспечивает ее эффективность в процессе дальнейшей эксплуатации. Важно заметить, что при реинжиниринге ИУС вследствие различных причин (изменение деловых процессов, реорганизация системы управления, замена устаревшей аппаратно-программной платформы и т.д.) «откат» назад может производиться до системного проекта. По оценкам специалистов разработка системного проекта занимает приблизительно 70-80% времени, затрачиваемого на разработку ИУС, в то время как реализация его на выбранном программно-аппаратном комплексе – соответственно 20-30%. Модификация самого системного проекта, как правило, не требует больших финансовых и временных затрат. Успех реинжиниринга достигается за счет предпроектного анализа и создания системных моделей исследуемых процессов. Модели необходимы для обеспечения связи всех этапов разработки информационной системы. В процессе создания системного проекта участвуют заказчик, аналитик, проектировщик, администратор системы, и именно модель служит языком их общения. Модель - это средство разработки системы, не зависящее от конкретной технической платформы. Лишь когда это решение получено, начинается создание баз данных и интерфейсов, причем существует достаточно много инструментов, позволяющих по модели построить информационную систему [311]. Анализ существующей системы, является наиболее трудной задачей, поскольку на базе такого анализа необходимо спроектировать изменение структуры, ответственности, методов и процедур принятия решений, которые превратят первоначальную систему обработки информации технологически в более совершенную. Принципы системного анализа применительно к информационным ресурсам и, соответственно, поддерживающих их информационно-управляющим, информационно справочным и др. системам позволили создать методологии для их автоматизированного проектирования. На основе этих методологий в передовых странах разработаны и применяются стандарты на системное проектирование. В США это стандарты SADT, в Англии это SSADM. Отличительной особенностью этих стандартов является то, что сам системный проект информационных систем (ИС) создается на языке, понятном предметным пользователям системы (подобно языку чертежей в машиностроительной области) и в электронном виде. 4. Применение CASE-технологий Одной из основных составляющих в области системного подхода и анализа является разработка языков структурного и объектного представления систем. CASE средства, используемые в качестве средств анализа и проектирования и предназначенные для построения и анализа как моделей деятельности организации, так и моделей, проектируемой системы, являются определяющим в процессах реинжиниринга Термин CASE ( Computer Aided System/Software Engineering) используется в довольно широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения, в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. С самого начала CASE-технологии развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет ее автоматизации и интеграции поддерживающих средств. Таким образом, CASE-технологии не могут считаться самостоятельными, они только обеспечивают, как минимум, высокую эффективность их применения, а в некоторых случаях и принципиальную возможность применения соответствующей методологии. Преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему: -улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации. -возможность повторного использования компонентов разработки. -поддержание адаптивности и сопровождения ЭИС. -снижение времени создания системы, что позволяет на ранних стадиях проектирования получить прототип будущей системы и оценить его. -освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор. -возможность коллективной разработки ЭИС в режиме реального времени. CASE-технологии в рамках методологии включает в себя методы, с помощью которых на основе графической нотации строятся диаграммы, поддерживаемые инструментальной средой. CASE (Computer-Aided Software Engineering)-технология представляет собой совокупность методологий проектирования и сопровождения программного обеспечения на всем его жизненном цикле, поддержанную комплексом взаимоувязанных средств автоматизации. CASE - это инструментарий для аналитиков и разработчиков, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки программного обеспечения. CASE-технологии использовались в реинжиниринге практически с момента его появления. Поэтому исторически большинство фирм разработчиков основывали свои подходы к реинжинирингу, исходя из CASE-технологии разработки информационных систем. В настоящее время CASE-системы прочно вошли в практику программной индустрии. При этом они используются не только (и не столько) как комплексные технологические конвейеры для производства программных систем, но и как мощный инструмент решения исследовательских и проектных задач, связанных с начальными этапами разработки, таких как анализ предметной области, разработка проектных спецификаций, выпуск проектной документации, планирование и контроль разработок, моделирование деловых приложений с целью решения задач оперативного и стратегического планирования и управления ресурсами и т.п. К средствам, распространяемым на Российском рынке относятся Bpwin, Silverrun, Oracle Designer, основанные на структурном подходе к проектированию, а также Ratoinal Rose, Re Think, основные на объектно-ориентированном подходе. При этом CASE средства используются в рамках определенных стандартов и методологий, составляющих основу методологий процесса реинжиниринга. 5.Основные понятия CASE-технологий и CASE-средства 5.1.Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект. Метод- это процедура или техника генерации описаний компонентов ЭИС (например, проектирование потоков и структур данных). Нотация – отображение структуры системы, элементов данных, этапов обработки с помощью специальных графических символов диаграмм, а также описание проекта системы на формальных и естественных языках. Инструментальные CASE- средства -это специальные программы, которые поддерживают одну или несколько методологий анализа и проектирования ИС. В практике использования CASE-средств для бизнес – проектирования выделяют два подхода: структурный и объектный. 5.2.Структурный подход. В основу функционально-модульного или структурного подхода положен принцип функциональной декомпозиции, при которой структура системы описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами. Сущность структурного подхода заключается в его декомпозиции на функциональные подсистемы, подфункции, задачи и процедуры, на ряде базовых принципов: • принцип иерархического упорядочения; • принцип абстрагирования; • принцип непротиворечивости; • принцип структурирования данных; • принцип формализации; • принцип управления; • принцип полноты; • принцип независимости данных; Для структурного метода характерно: • разбиение на уровни абстракции с ограничением числа элементов на каждом уровне от 3 до 7; • ограниченный контекст, включающий лишь существенные на каждом уровне детали; • использование строк формальных правил записи; • последовательное приближение к конечному результату. В рамках данного метода рассмотрены три важные идеи: расчленение больших систем на части (черные ящики, с обозначением функций, которые они включают), организация этих «черных ящиков» в виде иерархических структур и использование графических нотаций, служащих для облегчения понимания сложных систем. Структурный подход опирается на методологию SADT, которая в отличие от других, поддержана целым рядом САПРов, построенных на стандартах IDEF0, IDEF1, IDEF1X, IDEF/CPN и являющихся по сути подстандартами SADT, который является языком этих стандартов. В стандарте IDEF первоначально формируется единая информационная среда и система формализованных правил, позволяющих получить комплекс моделей, состоящий из: семантической, функциональной, информационной и динамической моделей. SADT-методология позволяет проанализировать все аспекты функционирования системы, а также последовательно приближает нас к использованию CASE-технологии, так как реализуется с помощью CASE-средства Design/IDEF, BP-Win, ER-Win [92, 148-150]. В SADT системные проекты выполняются с использованием языка структурного проектирования и соответствующих стандартов, причем весь процесс проектирования, дальнейшей модернизации и развития осуществляется в электронном виде (в едином информационном пространстве), что позволяет поддерживать высокую динамику развития системы. Рассмотрим CASE-средства поддерживающие методологии SADT в области проектирования систем. Средства Design/IDEF и BP-Win используется для создания функциональной модели (ФМ), которая является иерархически структурированным изображением функций производственной системы и ее связей со средой, семантики, отражающей эти функции. Наиболее распространенными средствами, описывающими функциональную структуру системы и отношения между данными являются: -DFD (Data Flow Diagrams) -диаграммы потоков данных; • SADT (Structured Analisis and Design Technigue) – метод структурного анализа и проектирования, - модели и соответствующие функциональные диаграммы; • ERD (Entity – Relationship Diagrans) – диаграммы «сущность – связь». Средство IDEF1 и ER-Win применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Информационная модель (ИМ) раскрывает реляционные свойства информационных образов реальных объектов по типу сущность - связь. Эти свойства полностью описываются правилами реляционной алгебры. Множество реальных объектов, представленных на ФМ дугами, преобразуются в сущности или отдельные атрибуты. IDEF/CPN и BP-Win позволяет построить динамическую модель (ДМ), отражающую изменение во времени поведения функций, информационных ресурсов, производственной системы или среды. Каждая из этих трех моделей или любое их сочетание позволяет сформировать "архитектуру" среды моделируемой системы. Эта среда включает другие системы, организации или технологии, которые должны работать совместно для достижения общей цели производственной среды или системы. Назначение модели, определяемой как "архитектура", заключается в том, что она графически представляет основные взаимоотношения в среде моделируемой системы - функциональные связи, идентификацию информационных потоков (общих, разделяемых, дискретных), а также динамическое взаимодействие ресурсов. Важно отметить, что IDEF0-модель становится архитектурой, когда она используется для более глубокого понимания и анализа не только производственной системы или ее окружения, но и того, как ее компоненты (подсистемы, организации и технологии), взаимодействуют друг с другом. 5.3.Объектный подход. Существующие методы объектно-ориентированного анализа и проектирования включают как язык моделирования, так и описание процесса моделирования. Объектно – ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. При этом объект определяется как осязаемая реальность-предмет или явление, имеющие четко определяемое поведение, а класс – как множество структуры и поведения. А любой объект является экземпляром класса. Отмечается, что определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования. Отмечается также, что важным понятием объектного подхода являются полиморфизм, как способность класса принадлежать более чем одному типу, и наследование как построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Главным недостатком объектно ориентированных методологий автор считает отсутствие стандартизации для представления объектов и взаимосвязей между ними. Преодоление недостатков структурного и объектного подходов авторы [31, 62] видят в использовании унифицированной методологии UML (Unifiecd Modeling Language). В UML используются следующие ключевые диаграммы: • диаграмма классов; • диаграмма прецедентов; • диаграмма взаимодействий; • диаграмма состояний; • диаграмма компонентов; • диаграмма применения (развертывания) При этом первые четыре диаграммы интегрируются как представления бизнес – процесса, а последние две – как представление автоматизированной системы. Отмечается, что объектно ориентированные модели плохо понимаются непрофессионалами, в то время как структурные методологии обеспечивают на сегодня достижение одной из главных целей – снабжение всех участников проекта общим языком «для передачи понимания». Объектно – ориентированный подход использует объектную декомпозицию. При этом структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. При этом объект определяется как осязаемая реальность-предмет или явление, имеющие четко определяемое поведение, а класс – как множество структуры и поведения. А любой объект является экземпляром класса. Отмечается, что определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования. Отмечается также, что важным понятием объектного подхода являются полиморфизм, как способность класса принадлежать более чем одному типу, и наследование как построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. Главным недостатком объектно ориентированных методологий автор считает отсутствие стандартизации для представления объектов и взаимосвязей между ними. Преодоление недостатков структурного и объектного подходов авторы [31, 62] видят в использовании унифицированной методологии UML (Unifiecd Modeling Language). В UML используются следующие ключевые диаграммы: • диаграмма классов; • диаграмма прецедентов; • диаграмма взаимодействий; • диаграмма состояний; • диаграмма компонентов; • диаграмма применения (развертывания) При этом первые четыре диаграммы интегрируются как представления бизнес – процесса, а последние две – как представление автоматизированной системы. Отмечается, что объектно ориентированные модели плохо понимаются непрофессионалами, в то время как структурные методологии обеспечивают на сегодня достижение одной из главных целей – снабжение всех участников проекта общим языком «для передачи понимания». Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и других. UML содержит стандартный набор диаграмм для моделирования: Характерным CASE средством объектно-ориентированного анализа и проектирования, основанным на языке UML, является Rationale Rose фирмы Rational Software Corporation. В результате разработки проекта с помощью CASE – cредства Rational Rose формируются следующие документы: • диаграммы UML, в совокупности представляющие собой модель разрабатываемой системы; • спецификация классов, объектов, атрибутов и операций; • заготовки текстов программ. Лекция 7.Организация внедрения ИС Организационные принципы управления проектом. Принятие решений о продвижении проекта. Разделение обязанностей и ответственности. 1.      Необходимые условия для достижения поставленных целей Необходимые условия отражают операционные потребности проекта, отсутствие которых непосредственно влияют на сроки, стоимость и даже принципиальную возможность достижения указанных целей. 1.      Сильная поддержка проекта со стороны Генерального директора предприятия Заказчика. 2.      Формирование совместной группы внедрения со стороны Исполнителя и предприятия Заказчика. Все члены группы должны участвовать в проекте на основе полного рабочего дня. 3.      Создание Координационного совета проекта и проведение его заседаний по утвержденному регламенту, но не реже одного раза в месяц. 4.      Назначение Координатора проекта в ранге не ниже заместителя Генерального директора предприятия Заказчика. 5.      Выделение ключевых пользователей из всех подразделений предприятия, участвующих во внедрении на период тестирования системы на срок не менее 2-х месяцев с освобождением 60% рабочего времени. 6.      Создание фонда материального стимулирования и использование его в согласии с предлагаемой предприятию Заказчика методикой. 7. Для эффективной организации работ по внедрению рекомендуется создать следующие структуры:          Координационный Совет          Центр компетенции          Группу внедрения 1. Место центра компетенции в организационной структуре Заказчика 2. Функциональная структура центра компетенции 3. Исполнители центра компетенции  2.       Координационный совет 2.1.Члены правления - высший коллективный орган проекта для организации работ, принятия результатов работ, а так же решения проблем, появляющихся в ходе проекта:         Утверждает результаты работы проектной группы и все основные документы проекта         Утверждает решения проблем 1-ой и 2-й категорий важности или решает эти проблемы         Утверждает изменение рамок проекта. Приглашенными участниками Координационного Совета могут быть:         Менеджер проекта         Члены группы управления проектом         Руководители структурных подразделений        2.2.Координатор проекта Лицо, в ранге не ниже заместителя Генерального директора предприятия Заказчика, непосредственно отвечающее за проект. Его права и обязанности:         Координатор имеет право сам принимать оперативные административные решения, а также добиваться исполнения административных решений Координационного совета.         Распоряжается выделенными на проект фондами.         Утверждает изменение рамок проекта, обеспечивая при необходимости дополнительное финансирование.         Принимает результаты проекта.         Выносит возникшие проблемы 1-й категории на Координационный совет и контролирует выполнение принятых соответствующих постановлений.         Решает возникшие проблемы 2-ой и 3-ей категорий         Отвечает за согласование различных организаций и групп, участвующих в проекте, отслеживает график работ и своевременность реализации принятых решений.         Проводит в жизнь административные решения Координационного Совета, касающиеся подразделения Заказчика. Руководит оперативным планированием загрузки сотрудников подразделения Заказчика и принимает решение об их премировании. 3.Центр компетенции 3.1.Менеджер проекта Менеджер проекта является функциональным руководителем всех работ со стороны Исполнителя, осуществляемых в структуре предприятия Заказчика:         Разрабатывает сценарии и планы проекта, устав проекта, а так же процедуры принятия решений и стандарты оценки достигнутых результатов;         Участвует на уровне координационного совета в принятии стратегических решений по ходу выполнение проекта;         Представляет все результаты работ групп внедрения;         Своевременно – еженедельно и по окончании очередного этапа на одном из объектов – отчитывается перед Координатором Проекта о состоянии дел на проекте;         Регулярно передает Координатору Проекта журнал регистрации проблем.  3.2.Группа управления проектом.  Со стороны Заказчика оперативное управление проектом осуществляется Группой управления проектом. Члены группы имеют статус заместителя Менеджера проекта и каждый из них осуществляет оперативное управление по своей функциональной области. Один из членов является 1-ым заместителем Менеджера и осуществляет координацию работ данной группы. Заместители менеджера назначаются по следующим функциональным областям:         Моделирование, кастомизация      Финансы         Производство         Проект (Технологическая подготовка производства). 3.3.Группа руководителей структурных подразделений Руководители структурных подразделений несут полную ответственность за внедрение ИС в подчиненных им подразделениях, предоставляют все необходимые условия для работы находящихся в их административном подчинении Ключевых Пользователей, контролируют выполнение планов их работ и отчитываются пред Координационным Советом.   3.4.Группа внедрения Группа, осуществляющая выполнение всех работ по проекту на объекте. Состоит из:         консультантов по функциональности Исполнителя,         консультантов-программистов группы сопровождения от предприятия Заказчика (создаваемого центра компетенции)         администратора бизнес-модели,         системных администраторов,         ключевых пользователей (KU). Сотрудники всей группы внедрения принимают активное участие в работах на объекте на фазе бизнес-моделирования, а также ведут доводку модели в ходе тестирования и опытной эксплуатации. Обеспечивают подготовку и корректировку всей документации проектного решения системы. 3.5. Консультант по функциональности БААН Консультанты по функциональности БААН IV осуществляют:         разработку общих и подробных спецификаций системы (подсистем);         определение необходимой готовой функциональности ИС для разработки системы;         разработку предложений о необходимой специфической функциональности проекта;         определение процедур ввода данных и необходимых значений параметров настройки системы ИС для данной организации         разработку и осуществление мероприятий по подготовке и обучению ключевых пользователей заказчика;         тестирование внедряемой системы, ее подсистем, отдельных программных модулей; 3.6.Консультанты – программисты Консультанты-программисты являются работниками ОАСУП. Консультанты-программисты группируются по функциональным направлениям, соответствующим крупным подсистемам ИС:         Финансы         Производство         Логистика         Проекты Специалисты, занимающиеся администрированием бизнес-модели и системы, не входят ни в одну из перечисленных групп. Функции консультантов-программистов:         принимать непосредственное участие во внедрении системы БААН на предприятии         осваивать функциональность и идеологию системы БААН         контактировать с консультантами и разработчиками БААН по вопросам внедрения и сопровождения работающей системы         непосредственно осуществлять настройку системы под руководством специалиста компании БААН         принимать непосредственное участие во вводе/конвертации данных, необходимых для ввода системы в эксплуатацию. Руководить процессом ввода данной информации конечными пользователями.         участвовать в разработке учетных методов на предприятии         регистрировать и анализировать пожелания пользователей к работе системы 3.7.Администратор бизнес - моделирования Администратор бизнес-моделирования ведет оперативный аудит принимаемых в ходе работ решений, контролирует целостность и процесс корректировки базовой бизнес-модели, отслеживает оптимальность кодирования справочников и руководит процессом разработки интерфейсов ИСУ БААН с другими подсистемами. Администраторы бизнес - моделирования осуществляют:         обследование организации и сбор информации, необходимой для создания бизнес-модели организации;         описание бизнес-модели организации, прорисовывают бизнес-функции и бизнес-процессы организации;         консультации специалистов заказчика по проведению необходимого реинжиниринга бизнес-процессов в организации;         анализ текущего состояния части проекта, относящейся к области деятельности проектной группы;         разработку и осуществление мероприятий по подготовке и обучению ключевых пользователей заказчика; 3.8.Системный администратор Системный администратор отвечает за вопросы связанные с:         инсталляцией и обновлением версий ИС         администрированием СУБД и ОС         телекоммуникацией между удаленными рабочими местами         санкционированием прав доступа и т.п. 3.9. Ключевые пользователи Ключевые пользователи набираются из состава отделов Предприятия, задействованных во внедрении. Ключевые пользователи участвуют в настройке и тестировании бизнес-модели Предприятия, а также передают полученные в ходе работ на проекте знания Конечным Пользователям Системы. Ключевые пользователи принимают участие в разработке учетной политики Предприятия и отвечает за реинжиниринг бизнес-процессов. В ходе работ по проекту выполняет функции технического согласования принимаемых решений с руководством предприятия Заказчика, а также ведет контроль правильности реализаций этих решений на фазах тестирования и опытной эксплуатации. Ключевые Пользователи обязаны постоянно повышать уровень своих знаний о системе, так как их должность является постоянной.         Ключевые пользователи Центр компетенции состоит из ключевых пользователей, ответственных за определенные участки хозяйственной деятельности. Центр компетенции подчиняется руководителям проекта со стороны БААН и Заказчика и контролируется членами руководящего комитета. Ключевыми пользователями должны быть компьютерно-грамотные специалисты, обладающие максимально возможными знаниями по данному участку автоматизации и имеющие возможность посвятить часть своего рабочего времени настройке системы.  Задачи ключевых пользователей:         Принимать непосредственное участие во внедрении системы БААН на предприятии         Осваивать идеологию и функциональность системы БААН         Участвовать в разработке учетных методов на предприятии         Следить за актуализацией настроек системы в соответствии с изменениями требований законодательства, рынка, стратегии развития предприятия и т.д.         Контактировать с консультантами и разработчиками БААН по вопросам внедрения и сопровождения работающей системы         Участвовать в процессе реинжиниринга предприятия         Планировать работы и распределение людских ресурсов по вводу начальных данных в систему         Регистрировать и анализировать пожелания, претензии и рекомендации конечных пользователей к работе системы. 4.Методология внедрения ИС. Весь проект разбивается на три фазы:         Бизнес-моделирование         Тестирование         Опытная эксплуатация Сложность и масштабность процесса внедрения крупных информационных систем ERP-класса обуславливает необходимость планирования каждой фазы в отдельности - по принципу поэтапного уточнения. План внедрения носит характер не последовательного графика, а состоит из нескольких, исполняющихся зачастую параллельно друг другу, рабочих заданий. Начиная с фазы Бизнес-Моделирования, работы по проекту разбиваются на отдельные рабочие задания. Данные рабочие задания представляют собой план работ по достижению одной или нескольких целей проекта. Рабочее задание является основным документом контроля исполнения Исполнителем договора субподряда на оказания консалтинговых услуг. 4.1.     Бизнес-моделирование Цель фазы: Группа внедрения должна получить по возможности наиболее полное представление о Предприятии – достаточное для проведения полноценного тестирования будущей модели предприятия. Предприятие получает возможность уточнить и дополнить перечень целей внедрения, оценить реальность их достижения путем рассмотрения сценариев внедрения и проектного решения.  Результаты: 1.1.       Пояснительная записка – обследование предприятия 1.2.       Предварительный перечень целей внедрения 1.3.       Предварительный план мероприятий по структурно-функциональному реинжинирнгу предприятия 1.4.       Предварительный сценарий внедрения 1.5.       Проектное решение 1.5.1.      Блок-схемы бизнес - процессов 1.5.2.      Табличные описания функций 1.5.3.      Макеты выходных документов. 1.5.4.      Вербальное описание методик работы с системой 1.6.       Окончательный план мероприятий по структурно-функциональному реинжинирнгу предприятия 1.7.       Уточненный сценарий внедрения (Фаза 1) 4.2.     Пилотное Тестирование Цель фазы: Предприятие получает возможность протестировать систему, т.е. получить представление о степени готовности своих сотрудников и управляющего состава к работе в новой системе. Результаты: 2.1.       Адаптированная бизнес-модель предприятия 2.2.       Описание контрольного примера тестирования 2.3.       Дополнения к проектному решению: 2.3.1.      Образцы выходных форм 2.3.2.      Справочники 2.3.3.      Перечень рабочих мест системы 2.3.4.      Служебные инструкции пользователей 2.3.5.        Должностные инструкции 2.3.6.        Регламенты взаимодействия отделов 2.3.7.        Методики управления 2.3.8.      Копия приказа о порядке запуска системы в опытную эксплуатацию 2.4.       Акт приемки тестовой эксплуатации системы 2.5.       Перечень замечаний по доработке модели 2.6.         Приказ об учетной политике 2.7.       Уточненный сценарий внедрения (Фаза 2) – план «миграции» – перехода на новую систему 4.3.     Внедрение и развертывание Цель фазы: Начать промышленную эксплуатацию ИСУ БААН. Результаты: 3.1.       Акт выверки сконвертированных данных 3.2.       Регламенты взаимодействия ИСУ БААН с существующими системами 3.3.       Приказы по предприятию (в соответствии с перечнем мероприятий по реинжинирингу) 3.4.       Акт приемки системы в промышленную эксплуатацию с перечнем доработок и оценкой степени достижения поставленных целей. Лекция 8. Разработка стратегии развития предприятия. Построение организационной структуры управления предприятием. 1. Разработка стратегии развития предприятия. 1.1. Понятие стратегии. Стратегия- образ действий руководителей, стремящихся достичь целей организации. Фактическая стратегия компании – это сочетание запланированных действий и тех действий, которые она предпринимает в ответ на изменение условий. Разработка стратегии организации является составной частью общего процесса стратегического управления, включающего три взаимоувязанных этапа: -планирование стратегии (стратегическое планирование), позволяющее учитывать множество факторов и сложнейшую комбинацию их взаимовлияния, оно заменяет интуитивный подход к определению направления развития организации и долгосрочное планирование, базирующееся на сохранении в будущем тенденций, проявившихся в прошлом -разработку программ, форм и методов реализации стратегии, определение необходимых изменений в структуре, культуре и ресурсах организации -оценку и контроль выполнения запланированных действий, обеспечение соответствия между прогнозируемыми и реальными факторами и условиями, выявленные отключения являются сигналом для регулирования и корректировки системы планов организации. Разработка стратегии организации является составной частью общего процесса стратегического управления, включающего три взаимоувязанных этапа: -планирование стратегии (стратегическое планирование), позволяющее учитывать множество факторов и сложнейшую комбинацию их взаимовлияния, оно заменяет интуитивный подход к определению направления развития организации и долгосрочное планирование, базирующееся на сохранении в будущем тенденций, проявившихся в прошлом -разработку программ, форм и методов реализации стратегии, определение необходимых изменений в структуре, культуре и ресурсах организации -оценку и контроль выполнения запланированных действий, обеспечение соответствия между прогнозируемыми и реальными факторами и условиями, выявленные отключения являются сигналом для регулирования и корректировки системы планов организации. Стратегия организации состоит из действий, предпринимаемых руководством для достижения поставленных целей, и деловых подходов, используемых при этом, и формируется на четырех организационных уровнях. Корпоративная стратегия – стратегия для компании и всех входящих в нее бизнесов в целом. • Действия, направленные на осуществление диверсификации. • Инициирование действий, направленных на усиление суммарной производительности тех бизнесов, в которых компания диверсифицировалась. • Поиск путей достижения взаимосвязи родственных видов бизнеса для повышения конкурентоспособности. • Установление инвестиционных приоритетов и направление корпоративных ресурсов в наиболее привлекательные виды бизнеса. Стратегия бизнеса – стратегия для каждого отдельного бизнеса, сделавшего компанию диверсифицированной. Центральным моментом в стратегии бизнеса является ответ на вопрос, как создать и укрепить конкурентную позицию компании на рынке. Стратегия бизнеса становится мощной, когда она создает значительное и устойчивое конкурентное преимущество. Она является слабой, когда результатом ее реализации становится отсутствие конкурентного преимущества. Функциональная стратегия – стратегия для каждой функциональной службы внутри бизнеса: научных исследований и разработок, производства, отдела маркетинга, сервисной службы, финансов, отдела кадров и т.д. Бизнес должен иметь столько функциональных стратегий, сколько и основных функциональных служб. Создание скоординированных, взаимно укрепляющих друг друга функциональных стратегий – важнейшее условие максимальной поддержки общей стратегии бизнеса. Оперативная стратегия – стратегии для основных рабочих подразделений: производств, торговых участков и регионов, отделов в функциональных службах, - определяет, как ими управлять и как решать стратегически важные оперативные задачи. 1.2. Определение стратегического видения и миссии. 1.2.1.Формулирование стратегического видения (“Куда мы направляемся”). Жизнь любой организации начинается с определения ее предназначения, или, по англо-язычной терминологии, видения того, чем она должна стать для потребителей ее продукции или услуг, для региона, в пределах которого она действует, и для общества в целом в ближайшие 10-20 лет. Обычно формулировку видения осуществляют высшее руководство или учредители компании, ставя перед собой такие вопросы: -Какой мы хотим видеть свою организацию в будущем? -В чем состоит наш бизнес сейчас и каким он будет в будущем? -Кто является потребителем нашей продукции (услуг) и на какую группу покупателей организация будет ориентироваться в будущем? -Какими способами мы собираемся увеличивать ценность нашей продукции для потребителей? Ответы на эти вопросы должны быть тщательно продуманы, так как на них базируется последующая работа по формулированию миссии и целей организации. Стратегическое видение - видение будущего направления развития организации и ее делового курса, важное понятие, определяющее, что организация стремится сделать и какой стать. Хорошо осмысленное стратегическое видение готовит компанию к будущему, помогает установить долгосрочные направления развития и указывает на намерение компании занять определенные позиции в бизнесе. 1.2.2.Формирование миссии (“Чем мы занимаемся”). Миссия конкретизирует видение организации, давая представление о философии, концепции и смысле ее существования. Она содержит информацию о сфере деятельности, ключевых целях и принципах работы, о рынках, находящихся в фокусе интересов организации, что должно заинтересовать другие организации, поставщиков, потребителей, простых людей, вызывать доверие и мотивировать их поступки по отношению к данной организации. Миссия мобилизует людей на действия по достижению поставленных целей, объединяет их. Она должна быть жизненно важной для сотрудников. Поэтому определение миссии имеет не только идеологический смысл, но и носит сугубо прагматический характер. Миссия помагает компаниям добиваться успеха. Она формулируется вне временных рамок и по существу представляет собой обоснование высшим руководством необходимости существования данной организации для общества. Поэтому ее основные положения должны соответствовать концепции общественного развития. Миссия организации - управленческий ответ на вопрос: “Каким является наш бизнес и что мы хотим сделать для наших потребителей?” В заявлении о миссии подробно описывается деятельность организации и ее состав.Хорошо сформулированная миссия рождает энтузиазм по поводу будущего курса развития, намеченного руководством. Мотивационной целью распространения содержания миссии является привлечение к ее реализации всех работников организации. Миссия- это очень важное, заявление, отражающее общественно значимые намерения организации. Хорошо продуманная и грамотно сформулированная миссия обладает реальной управленческой ценностью: • в ней выкристаллизовывается общее мнение старшего руководства относительно долгосрочного направления деятельности компании и ее характера, • она снижает риск “слепого” управления и бесконтрольного принятия решений, • она выражает цели организации и определяет, что мотивированные работники должны стараться изо всех сил и делать свою работу наилучшим образом, • она указывает ориентиры для руководителей более низкого звена, которые могут быть использованы для формирования миссии подразделений, определения их целей, профессиональных функций и стратегий подразделений, соответствующих направлению деятельности и стратегии компании, • она помогает организации подготовиться к будущему. 1.3. Проведение SWOT-анализа 1.3.1. Анализ внешних угроз и возможностей. 1.3.2. Анализ сильных и слабых сторон организации. 1.3.3. Формирование дерева целей. “Если вы хотите получить посредственные результаты, то установите посредственные цели” (Митчелл Лейбовиц). 1.4.Формирование целей 1.4.1.Содержание и структура понятия “Цели” Цели - это конкретизация миссии организации в форме, доступной для управления процессом их реализации. Цели – это ориентиры, по которым прослеживаются качество работы и прогресс организации. Наукой и практикой наработаны требования, которые необходимо учитывать при разработке целей организации. Это: -четкие временные рамки, на которые устанавливаются цели (стратегические, долгосрочные, и краткосрочные) -конкретность содержания и реальная достижимость целей -непротиворечивость и согласованность с другими целями, а также с ресурсами, потребными для их достижения -адресность (кто? когда? где?) и возможность осуществления контроля в ходе реализации целей. Компании, руководители которых устанавливают цели по каждой группе ключевых показателей, а затем предпринимают агрессивные действия, направленные на достижения этих целей, обычно обгоняют те компании, руководители которых имеют благие намерения, много работают и надеются на успех. 1.4.2.С точки зрения всей компании, существуют два основных критерия работы: финансовые и стратегические цели. Финансовые цели- цели, которые руководство устанавливает для финансовой деятельности организации. Финансовые цели обычно выражаются в росте прибылей, дохода на инвестиции, кредитоспособности, потоке денежных средств и доходах акционеров. Стратегические цели указывают, что руководители должны также увеличить конкурентную силу компании и улучшить долгосрочные перспективы. Стратегические цели- цели, которые руководство устанавливает для укрепления деловых позиций организации и ее конкурентоспособности. Стратегические цели должны быть сконцентрированы на конкурентах. Обычно они направлены на свержение того конкурента, который считается лучшим в отрасли по какой-то конкретной категории. Одним из важнейших критериев является период времени, на который устанавливаются цели. По этому критерию выделяют три группы целей: стратегические, долгосрочные и краткосрочные -стратегические, устанавливаемые на длительный период (его продолжительность колеблется в зависимости от состояния и устойчивости развития экономики от одного года до 5-10 лет) -долгосрочные, являющиеся логическим развертыванием стратегических целей и устанавливаемые на более короткие периоды (от одного до 5 лет для условий стабильного развития) -краткосрочные, представляющие собой конкретизацию стратегических и тактических целей до уровня задач, которые должны решать конкретные исполнители в своей повседневной работе. Краткосрочные цели – ближайшие цели организации. Величина краткосрочных улучшений сигнализирует о том, насколько быстро руководство стремится достичь долгосрочных целей. 1.4.3.Формирование дерева целей. Для того чтобы стратегическое мышление и принятие стратегических решений стали неотъемлемой частью организационного поведения, основные цели должны устанавливаться не только для организации в целом, но и для каждого отдельного филиала, частей ассортимента, функциональных служб и подразделений. Дерево целей позволяет описать упорядоченную иерархию целей и задач, полученную в результате декомпозиции главной цели организации. При этом используются следующие принципы: -главная цель, находящаяся в вершине графа, должна содержать описание конечного результата -при развертывании главной цели в иерархическую структуру целей соблюдается правило: реализация подцелей каждого последующего уровня является необходимым и достаточным условием достижения цели предыдущего уровня -количество уровней декомпозиции зависит от масштабов и сложности поставленных целей, принятой в организации структуры, иерархии ее менеджмента • при формулировании целей разных уровней описывать желаемые результаты, а не способы их достижения • -подцели каждого уровня должны быть взаимонезависимы и не выводимы одна из другой • фундамент дерева целей должны составлять задачи, представляющие собой формулировку работ, которые могут быть выполнены определенными способами и в заранее установленные сроки. 2.Построение организационной структуры управления предприятием. 2.1.Общие вопросы построения оргструктуры. Системный подход определяет любую систему как совокупность элементов и их взаимосвязей. Взаимосвязи определяются как статические и динамические. Статические взаимосвязи определяют структуру системы, а динамические – процессы, протекающие в системе. Структура управления – это взаимосвязь элементов системы управления, например, организационная и финансовая. Организационная структура управления – это взаимоотношения подразделений и должностей в организации, распределение ролей, полномочий и ответственности междй ними, а также порядок функционально – технологических связей, возникающих в процессе управления. Основные типовые недостатки существующей оргструктуры (присущие более чем 70% предприятий): -чрезмерная замкнутость структурных подразделений на первых руководителей (как минимум - генеральный директор) и, как следствие, их перегрузка (невозможность выполнения свои функциональные обязанности) -наличие множества заместителей генерального директора и директоров с размытыми и пересекающимися диапазонами ответственности -отсутствует информационная поддержка деятельности предприятия (отдел автоматизации системы управления предприятием работает не на нужды конкретного пользователя; максимум, что обслуживается - бухгалтерия), в частности коммерческой и финансовой деятельности - разные аспекты единой службы работы с персоналом либо отсутствуют вообще, либо разнесены по функциональным подразделениям с различными уровнями подчиненности (отдел кадров, отдел работы с персоналом и отдел организации труда и заработной платы) -отсутствуют или присутствуют формально жизненно необходимые финансово-экономические и подразделения и реальный человек, несущий полную ответственность за результаты финансовой деятельности предприятия (финансовый директор) -отсутствует служба управления изменениями, которая определяет в конкретный момент времени ориентацию организации на требования внешней среды. -деловые и производственные процессы непрозрачны для руководства. -организационная структура устарела и не соответствует новым напрвлениям деятельности предприятия. -система менеджмента предприятия не обеспечивает требуемый уровень управляемости, что приводит к пересечению и дублированию функций. -численность персонала не сбалансирована по подразделениям и не соответствует поставленным задачам. -для документооборота характерны неупорядоченность, несвоевременность, недостоверность, противоречивость или дублирование информации. 2.2.Анализ функциональной организации структуры. Разрушительная конкуренция между функциональными отделами и подразделениями – результат монопольного положения каждой службы внутри предприятия, что заставляет считать работников этих служб незаменимыми в организации и претендовать на самые высокие “дивиденды” или место под крышей. Из практики мы видим постоянные конфликты между работниками бухгалтерии, финансового отдела и планово-экономического отдела, между отделом сбыта и производством, между производством и инженерными службами, между конструкторами и технологами и т.д. Все усилия работников уходят на внутреннюю конкурентную борьбу (“кто важнее в организации”) в ущерб основным усилиям, которые должны направляться на потребности клиентов. Знакомая картина: на предприятии нет живых денег для выплаты заработной платы своим работникам, но пришедший клиент, готовый заплатить живые деньги за продукцию, которая лежит на складе, не сможет ее получить. Это имело место на многих предприятиях. В функционально ориентированных структурах чрезмерно усложнен обмен информацией в силу внутренних бюрократических стандартов - передавать информацию наверх по цепочке начальнику функционального отдела для того, чтобы передать их начальнику другого функционального отдела, а затем уже передать вниз исполнителю. И это вместо того, чтобы передать информацию напрямую нужному получателю (срабатывает “ мнение” начальника-функционала “без меня не должна проходить ни одна информация к моим подчиненным и от них”). Результат такого управления - поговорка “продукт с самым длительным сроком поставки - управленческое решение”, а отсюда и потеря клиентов. Наконец, в функционально ориентированных структурах люди пекутся о своей функции, ”забывая” о целевых задачах предприятия. Этот подход жив до сих пор, и многие руководители российских предприятий убеждены, что альтернативы не существует. Оргструктура оказывает решающее влияние на работоспособность предприятия, но как показывает практика, большинство оргструктур построено так, что они скорее мешают эффективной работе, нежели содействуют ей. Это происходит потому, что в функционально ориентированной структуре отдельные подразделения часто полностью сосредоточиваются на своих частных функциональных задачах, не желая знать, что цель их существования - работать поставщиками для своих внутренних и внешних клиентов. Поэтому избежать последней ситуации возможно, переориентировав структуру на управление бизнес-процессами, создавая рабочие команды, которые укомплектованы всеми необходимыми специалистами и отвечают за весь процесс, а не за отдельную его часть, относящуюся к их технической специализации. Способ управления бизнес-процессами - процессные структуры - позволяет определить организационно-управленческую структуру и управлять самим предприятием. 2.3.Критерии оценки эффективности оргструктуры. • Подразделение административно подчиняется только одному руководителю • В подчинении у руководителя должно быть не более 7-8 подчиненных • В подчинении у руководителя должно быть не менее 2-х подразделений или служащих • Все функции, которые вы определили, должны быть за кем-то закреплены. • На каждую функцию должна быть только одна служба, одно звено, иначе возникает дублирование функций. Лекция 9 Построение организационно-функциональной модели предприятия 1.Проблемы организации процессов управления предприятием До настоящего времени менеджмент российских предприятий основан на неформальных процедурах принятия и проведения в жизнь управленческих решений и чаще всего опирается на неординарные личности, способные решать задачи в условиях дефицита управленческой информации и отсутствия упорядоченных бизнес-правил. Основными организационными документами являются организационная структура, штатное расписание, положения о подразделениях. Организационная структура обычно представляет собой древовидную схему. Положения о подразделениях и должностях показывают выполняемую работу и круг обязанностей и, таким образом, отображают разделение труда (ролей) в организации. Штатное расписание в организационном аспекте является раскрытием оргструктуры и показывает степень подчинения внутри структурных подразделений. Такое описание существовало на большинстве советских предприятий. Многочисленные перестройки на предприятиях за прошедшее десятилетие привели к сокращению персонала и связанному с этим перераспределению функций, в результате чего традиционный механизм распределения полномочий перестал работать. Также   появились и новые функции, характерные не просто для рыночной экономики, а могут быть связанными с функциями основного процесса «жизненного цикла продукции», пронизывающими все предприятие по горизонтали. Все это привело к тому, что существовавшая ранее традиционная организационная документация (должностные инструкции) перестала отражать действительность. Документированные процедуры, которые оговорены стандартом ИСО, имеются в лучшем случае для технологических производственных процессов. Первое, с чем придется столкнуться даже на самом «успешном» предприятии, это  полная неопределенность с документами, регламентирующими бизнес. В лучшем случае - это структурная схема, штатное расписание и давно не обновляемые должностные инструкции. Поэтому главной задачей первого этапа является восстановление документированности управленческой деятельности предприятия в традиционном формате - «кто–что». Опыт показывает, что на предприятии прежде всего необходимо разобраться «кто и что делает» или, другими словами, определить состав функций и ответственности. И это уже позволяет решить важную задачу в области управления предприятием – конкретизировать функции и взаимоотношения и, в том числе, снять неопределенность в требованиях. Подобное описание деятельности должно быть зафиксировано в системе регламентов, которые с одной стороны обозначают в сознании персонала, что именно от него ожидается, а с другой - служат основанием для регулярного проведения проверки соответствия реальных и нормативно установленных процессов. Такими регламентами могут быть те же «Должностные инструкции» - документы, описывающие обязанности сотрудников, виды ответственности, прав и полномочий, связанных с их реализацией, требования к сотруднику и т.п. Однако, трудности их создания с помощью существующих методов и, особенно, поддержания в актуальном состоянии, в настоящее время полностью подорвали доверие к этому основополагающему документу. Поэтому, важнейшей задачей, которую необходимо решить на предприятиях – это переход от неформальных методов управления к строго документированным процедурам и регламентам деятельности. Надо отметить, что документированность процессов является одним из основных требований стандартов менеджмента качества ISO9001, внедрение которых является одной из приоритетных целей для предприятий, если они собираются успешно конкурировать на рынке. Кроме того, эффективное освоение современных информационных технологий, без которых невозможен серьезный бизнес, интегрированный в мировую экономику, также требует полной организационной определенности. Однако статичное и раздробленное представление об организации не дает адекватной картины того, как живет, работает и развивается бизнес организации. Любая организация представляет собой сложный комплекс взаимоувязанных процессов, комплексное рассмотрение которых позволяет увидеть традиционные функции с точки зрения достижения результата, как целевой функции. Как реакция на недостатки традиционного подхода к организации управления появляется так называемый “процессныйподход”. Процессный подход к управлению считают то революционно новым, то хорошо забытым старым. Процессы, на самом деле, всегда были и есть в любой организации. Просто объектами управления они стали относительно недавно и то в редких компаниях. В отличие от руководства структурными подразделениями, выполняющими вполне определенные функции, процессный подход предполагает управление цепочкой взаимосвязанных операций, приводящих к некоторому осязаемому и оцениваемому результату и называемых бизнес-процессами. Бизнес-процессы образуются из множества связей между подразделениями, которые передают друг другу в некоторой очередности ключевое задание. Поэтапно спланированное задание или сформированная цель превращаются в конечный результат – товар или услугу. Новые технологии организации управленческих процессов, которые должны обеспечить создание реально работающих формальных механизмов, требуют в качестве первого шага создание организационно-функциональной модели предприятия. Это и есть первый шаг в постановке современного управления предприятием, который можно назвать «Организационным проектированием». Главная задача организационного проектирования – на основании формализованного подхода сформировать полный состав функций деятельности компании и довести эти функции до конкретного подразделения и должности. Такое описание процессов позволит существенно упростить построение организационно- функциональной модели компании, а также провести уточнение внутрифирменных регламентов управления. Кроме того, наличие полного описания бизнес-процессов и функций позволит провести управленческий анализ эффективности их выполнения и провести, в случае необходимости, реорганизацию. Таким образом, цель построения организационно-функциональной модели предприятия – это не только выявить бизнес-процессы и закрепить функции за исполнителями, что, безусловно, улучшает построение организационной структуры предприятия. Не менее важно зафиксировать полную систему взаимосвязанных процессов компании и степень влияния каждого из них на достижение ее целей. Однако, создание организационно-функциональной модели предприятия сталкивается еще с одной проблемой - это число документов, порождаемых системой управления. Проблема состоит в том, что при любом более или менее существенном изменении в деятельности предприятия, эти документы должны отражать текущее положение дел. Взаимосвязанная актуализация большого количества бумажных документов традиционными методами является практически невыполнимой задачей. Даже поддержание в актуальном состоянии таких важных документов, как стандарты предприятия, выливается в трудновыполнимую задачу. Переход к электронным формам и архивам хранения документов также не решал проблемы: изменения одного документа часто требуют изменения других, и поддержание системы взаимных ссылок также становится трудно разрешимой проблемой. Стало очевидным, что для организации документированной деятельности предприятий необходимы не только типовые методики и процедуры, а так же специальные программные средства, интегрированные с технологиями построения организационно-функциональной модели. Таким образом, построение организационно-функциональной модели предприятия или более коротко «бизнес-модели» должно быть обеспечено эффективными информационными технологиями, интегрирующими организационные структуры, бизнес-процессы, функции и документооборот. Безусловно, при этом должна функционировать эффективная технология регулярной актуализации как самой бизнес-модели, так и всех ее элементов. Разработанные для этого консалтинговой группой БИГ специальные технологии быстрой регуляризации бизнеса компании, закрепленные в наборах руководств - Органайзеров БИГ,- были и остаются до сих пор первым шагом и, пожалуй, единственным опытом в создании формализованного подхода к решению рассматриваемой проблемы. Разработанная БИГ-СПб технология систематизации процессов направлена на выявление и систематизацию процессов, представление их в виде непротиворечивой, целенаправленной системы. Данная технология с помощью матричных моделей описывает процессы, которые могут быть определены и описаны как статическая взаимосвязанная система. Спецификация каждого процесса в такой системе может быть выведена из бизнес-модели компании в отчет, например, такого формата: • Идентификатор и Наименование процесса • Назначение и цели процесса • Владелец процесса • Участники процесса • Предшествующий процесс (ы) • Следующий процесс (ы) • Преобразуемые ресурсы (на входе и выходе процесса) • Нормативные документы, регулирующие процесс • Документы или события инициирующие процесс • Документы или записи порождаемые процессом и т.д. За счет иерархической структуры классификаторов бизнес-модель одновременно содержит отношения «функция–исполнитель» всех степеней детализации, что позволяет с помощью встроенного генератора отчетов, настраивать «разрешение» взгляда на компанию применительно к конкретной управленческой задаче. Кроме того, взгляд на компанию может быть также связан с любой «координатой отсчета» - например, от документа или сотрудника – в каких процессах и как они участвуют и т.п. Однако широкое внедрение этих технологий затруднено по причине недостаточной формализованности процессов их построения и достаточно высокой трудоемкости. Учитывая, что бизнес-модель, это не только средство отражения деятельности предприятия и формирования регламентирующих документов, но прежде всего, бизнес-модель - это корпоративная память организации, верхний уровень ее базы знаний, сведений о том как построен бизнес, необходимы дальнейшие работы в направлении формализации и рационализации процессов их формирования. Освоение технологий бизнес-инжиниринга позволит приблизить российские предприятия к самым передовым достижениям мировой управленческой практики. А то, что это необходимо, осознали уже большинство менеджеров, столкнувшиеся с необходимостью конкурировать с западными компаниями не только на внешних но и на внутренних рынках и осознавшие, что качество менеджмента становится решающим фактором в этой конкурентной борьбе. 1.Теоретические основы построения организационно-функциональной модели предприятия 2.Методика построения организационно-функциональной модели предприятия. 2.1.Задачи формирования организационно-функциональной модели На этапе выхода из кризиса и роста предприятие в той или иной степени сталкивается с тремя основными проблемами: 1. Формирование стратегии развития предприятия, оптимизация организационной и функциональной структуры 2. Необходимость снижения информационной нагрузки на персонал и обеспечения руководителей и специалистов, принимающих решения, более оперативной и качественной информацией 3. Обеспечение сертификации предприятия в соответствии со стандартом ИСО 9001 и, прежде всего, решение задачи формирования и описания бизнес процессов и распределения функций и ответственности Как показывает практика совершенствования систем управления, решение отмеченных выше проблем проходит ряд общих этапов, обозначаемых в разных описаниях различными терминами, но имеющими общую теоретическую и методическую основу, называемую бизнес-моделированием или системным проектированием. Предлагаемая методика исходит из того, что при построении организационно-функциональной модели предприятия решаются следующие основные задачи: 1. Идентификация всего состава бизнес-процессов деятельности предприятия. 2. Формирование и закрепление за исполнителями полного состава функций, обеспечивающих результативное исполнение бизнес-процессов. 3. Формирование потоковых диаграмм выполнения функций конкретными исполнителями. 4. Формирование базы данных документов, моделей бизнес-процессов и документооборота. 5. Анализ эффективности бизнес-процессов предприятия и выработка рекомендаций по рационализации организационной структуры, технологии выполнения бизнес-процессов, построению информационной системы. Данный подход, опирается на следующие принципы менеджмента качества (см. ИСО 9004-2001), который, с нашей точки зрения является и стандартом общего менеджмента: • Лидерство руководителя. • Вовлечение работников. • Процессный подход. • Системный подход к менеджменту. • Постоянное улучшение. • Принятие решений, основанное на фактах. Важнейшим элементом процесса управления является конкретный исполнитель той или иной функции или конкретное подразделение, за которым закрепляется функция. По своей сути весь комплекс вопросов организации системного моделирования направлен на совершенствование деятельности конкретного субъекта процесса обработки информации и конкретного субъекта процесса принятия решений. Формализация, упорядочение и детализированное описание отношений «функция» – «субъект» является одной из важнейших задач формирования организационно-функциональной модели. В результате формируется организационно-функциональная модель предприятия, обеспечивающая: 1. Анализ производственной структуры предприятия и формирование состава бизнес-процессов 2. Формирование функций деятельности предприятия, распределение функций и ответственности, формирование положений о структурных подразделениях 3. Анализ документооборота, построение функциональных моделей процессов управления, формирование должностных инструкций персоналу 4. Анализ и упорядочение или реорганизация организационной структуры предприятия 5. Реинжиниринг бизнес-процессов и выработка рекомендаций по построению информационной системы предприятия 2.2.Этапы внедрения организационно-функциональной модели предприятия: 1. Описание производственной и организационной структуры предприятия, формирование состава бизнес-процессов и функций 2. Анализ и упорядочение распределения функций и ответственности, формирование положений о структурных подразделениях 3. Анализ документооборота, построение функциональных моделей процессов управления, формирование должностных инструкций персоналу 4. Анализ организационно-функциональной модели предприятия и выработка рекомендаций: 4.1. По совершенствованию организационной структуры 4.2. По реорганизации бизнес-процессов 4.3. По внедрению информационной системы 2.3.Описание производственной и организационной структуры предприятия, формирование состава бизнес-процессов и функций На первом этапе осуществляется подготовка базовой информации для постороения бизнес-модели, формируется матрица жизненного цикла ресурсов, дерево бизнес-процессов и состав функций деятельности предприятия. Рис. 1 – Фрагмент матрицы «Ресурсы-Процессы» Бизнес-процессы при этом рассматриваются как последовательности стандартного набора функций и дифференцируются на выбранном уровне технологических процессов. Все бизнес-процессы при этом определены и идентифицированы как вид деятельности, имеющий некое целевое назначение и результаты, и классифицированы по видам ресурсов и процессов их обеспечения. Также фиксируется организационная структура предприятия, штатное расписание и распределяется участие подразделений («кто – где») в реализации бизнес-процессов. Рис. 2 – Участие структурных подразделений в реализации бизнес-процессов 2.4.Анализ и упорядочение распределения функций и ответственности, формирование положений о структурных подразделениях Проводимый на втором этапе функционально-содержательный анализ позволяет осуществить упорядочение распределения управленческих функций на предприятии, выявление незакрепленных функций, функций, которые не свойственны тем или иным подразделениям, выявление случаев дублирования функций и др. Такой анализ осуществляется посредством определения на основе предложенной матрицы эталонного состава функций, сравнения его с фактически выполняемым и включает в себя: обследование и фиксирование состава функций управления, которые имеют место на предприятии; сравнение этого состава с эталонным и выявление незакрепленных функций или случаев их дублирования; закрепление полного состава функций за подразделениями Рис. 3 – Анализ закрепления функций за структурными подразделениями При этом устраняются неизбежные противоречия между сложившимися на практике представлениями о закреплении функций и их системным представлением и формируется признаваемый всеми исполнителями и отражающий полный набор закрепленных за ними классификатор функций «что они делают». Таким образом, мы фактически восстанавливаем или создаем (там где такого не было) описание существующей деятельности предприятия в виде «бизнес-процессы – функции – подразделения». Результатом этого этапа является организационная модель предприятия, совмещающая дерево организационной структуры и функции, выполняемые подразделениями и представленная в табличной форме. Рис. 4 – Пример «Положения о структурном подразделении» (фрагмент) 2.5.Анализ документооборота, построение функциональных моделей процессов управления Описание бизнес-процессов осуществляется на основе обследования документооборота с использованием методологии IDEF0. В качестве инструментария выбран программный пакет AllFusion Process Modeler (BPwin) 4.1. На контекстной диаграмме отображается сам БП. На втором уровне декомпозиции будут располагаться функции данного БП (планирование, исполнение, учет, анализ, регулирование). На третьем уровне описываются обеспечивающие данную функцию документы и маршруты их оформления. Для описания процессов деятельности и их декомпозиции выбирается методология IDEF3 и дальнейшее описание БП проводится в этой методологии. В IDEF3 методологии декомпозиция используется для детализации работ. Методология IDEF3 позволяет декомпозировать работу многократно, т.е. работа может иметь множество дочерних работ. Это позволяет в одной модели описать альтернативные или параллельные потоки. Окончание одной работы может служить сигналом к началу нескольких работ, или же одна работа для своего запуска может ожидать окончания нескольких работ. Перекрестки используются для отображения логики взаимодействия стрелок при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния и разветвления стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. Стрелки могут сливаться и разветвляться только через перекрестки. Различают следующие виды стрелок: Название Смысл в случае слияния стрелок Смысл в случае разветвления стрелок Асинхронное «И» Все предшествующие процессы должны быть завершены Все следующие процессы должны быть запущены Синхронное «И» Все предшествующие процессы завершены одновременно Все следующие процессы запускаются одновременно Асинхронное «ИЛИ» Один или несколько предшествующих процессов должны быть завершены Один или несколько следующих процессов должны быть запущены Синхронное «ИЛИ» Один или несколько предшествующих процессов завершены одновременно Один или несколько следующих процессов запускаются одновременно Исключающее «ИЛИ» Только один предшествующий процесс завершен Только один следующий процесс запускается В процессе выполнения работ осуществляется: • Формирование маршрутов движения документов, включая: ◦ альтернативные маршруты ◦ рекурсию в маршрутах ◦ закрепление исполнителей за операциями обработки документов • Вывод операций по исполнителю (какими операциями занимается конкретный исполнитель) • Оптимизация оргструктуры по связям между подразделениями, участвующими в маршруте документа (время согласования документа, частота обмена информацией по документу) 3.Формирование организационной документации: Таким образом, технология формирования организационно-функциональной модели предприятия решает задачу повышения уровня организации системы управления и позволяет в едином комплексе формировать и поддерживать в актуальном состоянии следующие документы: - Организационную структуру - Штатное расписание - Положения о подразделениях - Должностные инструкции - Модели бизнес процессов - Модели процессов деятельности Процедуры создания и актуализации данного комплекса определяются организационным документом – положением об организационной структуре Положение об организационной структуре – это внутрифирменный документ, фиксирующий взаимосвязи организационных звеньев, бизнес процессы, функции деятельности предприятия, распределение функций по звеньям. Главная цель документа – определить, кто и что делает. Количество функций для среднего предприятия измеряется тысячами, поэтому для их систематизации необходимо использовать современные программные продукты класса orgware. Кроме того, сбор информации и ее систематизацию невозможны без определенной методики, регламентирующей процесс по этапам. Таким образом, формирование модели управления предприятием является неотъемлемой частью системы регулярного менеджмента. Сам процесс оптимизации модели управления является итерационным, т.е. изменения в модель управления вносятся на основании выявленных недостатков и замечаний персонала в процессе работы предприятия. Изменения работы предприятия отражаются в модели управления в системном виде, что позволяет автоматически сформировать необходимый пакет документов. Системный подход, применяемый в технологии, позволяет добиться следующих качественных результатов: - Обосновать формирование и распределение функций по подразделениям - Обеспечить полноту выявления бизнес процессов предприятия и функций деятельности - Обеспечить оптимальное распределение функций по подразделениям - Упорядочить организационную структуру предприятия -Оценить и оптимизировать бизнес процессы предприятия и потоки документов - Выявить необходимость создания новых и ликвидации ненужных для управления форм документов Литература: 1. 7 нот менеджмента. - 5-е изд.доп. – М.: ЗАО «Журнал Эксперт», ООО «Издательство ЭКСМО», 2002. – 656 с. 2. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия “Реинжиниринг бизнеса”. - М.: СИНТЕГ, 2000. - 212с 3. Речкалов А.В., Куликов Г.Г. и др. Автоматизированное проектирование информационно-управляющих систем. Проектирование экспертных систем на основе системного моделирования (монография) Изд. УГАТУ, Уфа, 1999 4. А.С. Гринберг, И.А. Король «Информационный менеджмент», Юнити, М. 2003г.