Проектирование систем управления в менеджменте. Проектно-ориентированная система управления в организации

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

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

1) разработка технического задания на проектирование;

2) предварительное проектирование;

3) эскизное проектирование;

4) техническое (рабочее) проектирование;

5) серийное изготовление;

6) эксплуатация.

Рис. 4.1. Основные этапы проектирования системы управления

Качественная разработка технического задания на проектирование системы управления во многом определяет как уровень, так и успешность разработки системы управления.

Предварительное проектирование проводится с целью определения принципов построения системы управления и изыскания новых принципов, структур, технических средств, удовлетворяющих техническому заданию. Предварительное проектирование обычно относят к стадии НИР.

Эскизное проектирование и последующие этапы – это этапы опытно‑конст­рукторской разработки (ОКР). Результатом эскизного проектирования является детальная разработка возможности создания системы управления, удовлетворяющей заданным требованиям.

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

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

Особенности процесса проектирования

Систем управления

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

В 60-е годы изучение процесса проектирования осуществлялось на основе теории управления. При этом система проектирования рассматривалась как стационарная детерминированная
линейная САУ, в большинстве случаев как одномерная. Этот подход используется и до настоящего времени при проектировании систем управления относительно простыми объектами управления.

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

1. Отдельные управляемые подпроцессы автономны в том смысле, что каждый регулятор управляет ограниченным числом подпроцессов.

2. Управление подпроцессами происходит на основе относительно ограниченного количества информации.

3. Чем выше уровень управления, тем меньше требуется информации для его осуществления, т. е. при движении вверх по иерархии информация как бы уплотняется.

4. Существование цели управления для каждой подсистемы и общей цели для всей системы.

5. Взаимовлияние подпроцессов из-за ограничений на общую стоимость системы управления и как следствие – ограничения на штаты, оборудование и другие ресурсы.

Возможные математические модели процесса проектирования систем управления приведены на рис. 4.2.

Детерминированная математическая модель строится в тех случаях, когда факторы, влияющие на конечный результат процесса проектирования, поддаются точной оценке, а случайные факторы либо отсутствуют, либо ими можно пренебречь. Если факторы, влияющие на конечный результат процесса проектирования, являются случайными, то строится вероятностная математическая модель.

Поскольку процесс проектирования систем управления можно представить как процесс переработки информации, то для описания процесса проектирования может быть использована информационная математическая модель.

Рис. 4.2. Математические модели процесса

проектирования системы управления

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

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

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

Требования к математической модели процесса проектирования:

1) модель должна отвечать строго поставленной задаче – не должна быть точнее, чем это необходимо для решения данной конкретной задачи;

2) модель должна быть простой и удобной для анализа и в то же время предельно чувствительной к исследуемым переменным, при этом не должны учитываться второстепенные для решаемой задачи факторы;

3) усложнение модели излишними подробностями чревато тем, что влияние интересующих нас переменных «утонет» в совокупности влияния других факторов.

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

Особое место при проектировании систем управления занимает задача сбора информации. Эта информация должна включать в себя:

1) сведения о ранее спроектированных системах управления и комплектующих их изделиях;

2) характеристики проектируемых в настоящее время и предполагаемых к проектированию систем управления и устройств;

3) параметры технических средств;

4) характеристики сервисного оборудования;

5) совокупность требований к проектируемой системе управления;

6) информация о средствах вычислительной техники, используемой при проектировании системы управления, имеющихся алгоритмах решения проектных задач и программного обеспечения, реализующего эти алгоритмы;

7) информация об имеющемся производственном оборудовании, его возможностях.

Нетворческие процедуры проектирования в значительной степени поддаются формализации (алгоритмизации), что позволяет привлекать к исполнению ЭВМ, в частности, системы автоматического проектирования (САПР). Поэтому для их выполнения также возможно широкое использование САПР и, в первую очередь, при отборе и анализе различных вариантов проектирования систем управления.

Комплексное исследование системы управления в организации является основой её комплексного проектирования, которое включает в себя решение следующих задач:

выбор целей функционирования системы управления организацией;

формирование состава решений, направленных на реализацию этих целей;

моделирование организационных технологий процесса принятия решений;

формирование новой структуры управления или внесение изменений в действующую структуру;

разработка документации, регламентирующей деятельность системы управления организацией (положение о подразделении, должностные инструкции, правила работы исполнителей).

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

Проектировать новую систему управления под множество целей очень сложно. Поэтому количество целей по возможности следует сократить. Период действия целей также должен быть сопоставим с периодом проектирования новой системы управления. Необходимо произвести структуризацию целей, т.е. “построить дерево целей” . Для этого могут быть привлечены независимые эксперты, непосредственно не связанные с организацией.

При проектировании систем управления помимо экспертных методов широко используется моделирование, которое применяется при проектировании управленческих решений.

Количество управленческих решений, применяемых в организации, зависит от числа структурных подразделений этой организации. За каждым подразделением закрепляется группа решений (например, за бухгалтерией – решения по учету и анализу хозяйственной деятельности, за планово-экономическим отделом – решения по вопросам технико-экономического планирования и т.д.).

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

Моделирование управленческих решений требует совершенствования процесса подготовки и принятия управленческого решения на всех уровнях управления и по всем стадиям его разработки вплоть до принятия окончательного решения . Моделирование производится на основе спроектированной информационной модели.

Комплексное проектирование системы управления предполагает ее совершенствование на основе выбранных качественных целей функционирования и включает проектирование процесса принятия решений и структуры управления на уровне управленческих решений .

Проектирование системы управления включает в себя 6 этапов (см. с. 97). Ниже приведены пояснения к этой схеме.

1 этап . Определяется полный список управленческих решений, необходимых для функционирования системы управления организацией.

2 этап . Составляется перечень документов, используемых при подготовке и принятии управленческих решений. Часть документов являются общим при подготовке различных управленческих решений.

3 этап . Составляется перечень групп управленческих решений по функциям с таким расчетом, чтобы каждая из групп использовала минимальное количество документов для подготовки решений. Используются методы анализа и логики, а также ЭВМ.

Схема. Основные этапы проектирования системы управления

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

Распределение решений охватывает все уровни управления в организации.

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

6 этап. Разрабатываются документы, регламентирующие деятельность системы управления : положения о подразделениях, должностные инструкции, правила работы исполнителей.

В теме 3 была сформулирована концепция совершенствования организационного механизма управления, которая воплощена в схеме проектирования системы управления (см. с. 97). Достоинством предлагаемой концепции является то, что ряд этапов решается с помощью компьютерной техники, что упрощает системное проектирование.

Как правило, эффективное проектирование систем управления требует значительных инноваций.

Инновации – поиск, определение и реализация различных новшеств, нововведения в деятельности человека, отражающие его потребность в изменениях, развитии, модернизации, реконструкции, совершенствовании, реформировании и пр.

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

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

1) Системная концепция совершенствования организационного механизма управления включает в себя анализ системы управления как системы принятия решений исследование процесса управления и структуры управления (на уровне управленческих решений). По результатам анализа проектируется комплексная система управления, ориентированная на выбранные качественные цели, в конечном счете, совершенствования всей системы управления организации.

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

Инновации, направленные на совершенствование структур управления , должны способствовать приведению в соответствии структур управления и объектов управления, с другой стороны.

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

Проектирование системы управления организацией требует разработки инновационной стратегии , представляющей собой целенаправленный план внедрения инноваций по важнейшим направлениям совершенствования системы управления.

Инновационная стратегия реализуется через управленческие решения, отражающие специфику деятельности организации.

Основные положения инновационной стратегии отражаются в программе, в которой указываются цели, задачи, этапы ее реализации, взаимосвязанные по срокам, ресурсам и исполнителям.

ТЕСТЫ ДЛЯ САМОКОНТРОЛЯ

1. Основой комплексного проектирования системы проектирования системы управления является:

экспериментирование системы управления;

моделирование;

комплексное исследование;

наличие информации.

(ответ: с).

2. Назовите задачи, не решаемые в процессе комплексного проектирования системы управления: (1 тип, ПС)

изучение тенденций развития организации;

корректировка структуры управления;

формулировка миссии;

определение направлений исследования;

составление перечня решений.

(ответ: а + д).

3. Комплексное проектирование начинается с определения: (1 тип, С)

выбора миссии;

формулирования большого количества задач;

привлечения экспертов;

совокупности действий персонала, направленных на достижение целей.

(ответ: а).

4. В процессе проектирования системы управления применяется вычислительная техника: (1 тип, С)

(ответ: а).

5. Инновации – это: (1 тип, ПС)

боязнь риска; уход от нововведений; поиск новшеств (ответ: с).

6. При проектировании системы управления инновации направляются на:

совершенствование структуры управления;

повышение ответственности руководителей;

привлечение организационных технологий;

улучшение методов управления.

(ответ: а + с + д).

ТЕСТЫ ДЛЯ КОНТРОЛЯ

1.Возможно ли образование замкнутого контура при построении ’’дерева целей”: (1тип, ПС).

(ответ: б).

2. ’’ Дерево целей’’ относится к следующему виду графиков: (1 тип, ПС).

сетевой график;

диаграмма;

древовидный граф;

циклограмма.

(ответ: с).

3. ’’ Дерево целей ’’ – это: (1тип, ПС)

распределение целей по подразделениям организации;

распределение целей по уровням управления;

делегирование целей;

взаимодействие целей организации.

(ответ: б).

4. Методы проектирования систем управления: (1 тип, ПС)

способы проведения проектирования;

средства оптимизации проектирования;

основные этапы проектирования (ответ: б).

5. Установите взаимосвязь между исследованием и проектированием системы управления: (1 тип, П)

проектирование предшествует исследованию;

проектирование осуществляется параллельно исследованию;

исследование предшествует проектированию;

исследование и проектирование никак не связаны между собой.

(ответ: с).

6. Инновационная стратегия проектирования системы управления – это:

(1 тип, ПС)

общий, всесторонний план достижения целей;

целенаправленный план внедрения инноваций;

способ использования средств и ресурсов, направленных на достижение поставленной цели;

генеральная программа действий для достижения главной цели.

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

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

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

Для построения организационных структур проектных организаций наиболее часто используется проектный принцип. На основе этого принципа формируется организационное подразделение - проектная группа (проект), которая предназначена для одноразовой разработки ИС. Специалисты проектной группы образуют автономную организационную единицу, руководитель (главный конструктор) которой имеет соответствующие полномочия и несет полную ответственность за результаты деятельности проектного коллектива, который после выполнения проекта может быть расформирован.

Матричный принцип построения организационных структур предполагает формирование в организации – разработчике ЭИС из специалистов функциональных подразделений проектных групп для разработки конкретных проектов. При этом специалисты не теряют принадлежности к соответствующему функциональному подразделению и находятся в двойном подчинении: у руководителя проекта (ответственность по проекту) и у руководителя функционального подразделения (организационная ответственность).

Матричные структуры применяются в условиях высокой степени кооперации функциональных подразделений. Эти структуры основаны на особом механизме взаимодействия функциональных и проектно-целевых подсистем аппарата управления проектной организации. Главная особенность матричных структур состоит в обязательном выделении конкретного лица – руководителя проекта, наделенного всей полнотой ответственности за достижение цели проектирования и значительными правами распорядительства, которые делегируют ему вышестоящим руководством.

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

Потенциал коллектива разработчиков;

Объем и сложность разрабатываемых проектов;

Технология проектирования системы;

Модель жизненного цикла системы.

Структуры проектной группы

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

Централизованная организационная структура проектной группы предусматривает в качестве руководителя специалиста высокой квалификации, осуществляющего административное и техническое руководство. Он же является основным посредником между группой, заказчиком проекта и внешними организациями.

Децентрализованная организационная структура проектной группы имеет свойство двух вышеизложенных структур. Данная организационная структура применяется в коллективах с большой численностью разработчиков (свыше 10 человек), осуществляющих проектирование больших ЭИС, декомпозируемых на подсистемы (контуры, модули) и комплексы задач.

Структура организации работ по проектированию ИС, характерная для организации - разработчика

В организационном аспекте управление проектированием рассматриваются по уровням организационно-административной структуры с соответствующими правами и обязанностями субъектов процесса проектирования.

Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком.

Пользователь – это организация или группа подразделений, которые используют результаты обработки информации на ЭВМ.

Для ИС под пользователем понимают прежде всего административно-управленческий аппарат, для которого создается эта система. Пользователь выполняет следующие функции:

Формирует исходные данные для проектирования и обработки;

Определяет состав задач для автоматизации;

Определяет основные требования к задачам и режим функционирования системы.

Заказчик – это ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции:

Формирует требования к системе и ее частям;

Выдает техническое задание, финансирует разработку ЭИС;

Обеспечивает проведение комплекса мероприятий по ее созданию;

Проводит внедрение и прием проекта ЭИС.

При этом заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ЭИС исходным данным пользователя, за сроки создания системы, правильность использования ресурсов в процессе проектирования.

Администратор – ответственное лицо, которое выполняет эксплуатацию программно-технических средств и информационного и методологического обеспечения ЭИС (технологические и инструкционные карты).

Администратор несет ответственность перед пользователем за правильность результатов работы ЭИС и их своевременность, а перед заказчиком и разработчиком – за соблюдением условий эксплуатации, требований к технической документации.

Разработчик– это ответственное лицо (организация или подразделение), которое выполняет следующие функции:

Разрабатывает ЭИС по техническому заданию заказчика;

Принимает участие во внедрении;

Осуществляет сдачу проекта заказчику;

Разработчик несет ответственность перед заказчиком за правильность реализации требований ТЗ на ЭИС, научно-технический уровень разработки, сроки проведения работ, качество проектной документации, правильность расхода денежных ресурсов.

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

Существует несколько типов схем организации работ с участием сторон, выбор которых зависит от объема заказа.

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

К преимуществу данной схемы можно отнести минимальное количество организаций – участников процесса и минимальные сроки и стоимость разработки.

Однако совмещение в одной организации функций разрабатывающей стороны и принимающей стороны имеет ряд существенных недостатков:

Отсутствует действенный контроль за научно-техническим уровнем разработки, сроками выполнения работ;

Не достигается высокого профессионального уровня разработчиков.

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

К преимуществам данной схемы можно отнести:

Рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС;

Возможность привлечения к разработке ЭИС специализированных организации (НИИ, СКБ).

Однако и эта схема имеет недостатки:

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

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

3. В том случае, если заказчик – большая организация, которая курирует разработку нескольких проектов ЭИС, применяют схему, в которой на заказчика возлагаются функции сопровождения, заказа и приемки проектов нескольких ЭИС.

Преимуществами данной схемы являются:

Более высокая степень специализации работников, следовательно, более высокий профессиональный уровень;

Возможность организации контроля за сроками и качеством выполнения работ.

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

Основными документами, регулирующими отношения заказчика и проектировщика, являются техническое задание и договор на проведение работ.

Структурные схемы для информационной службы предприятия

Существуют три вектора, по которым целесообразно выстраивать первый уровень в организационной иерархии:

1. функции,

2. клиенты,

3. продукты.

Организация по функциям

Разбиение по функциям применяется чаще всего, особенно в информационных службах. Например, Управление состоит из подразделений:

Отдел анализа и документирования технологий,

Отдел прикладных систем,

Отдел телекоммуникаций,

Отдел системотехники и базового ПО.

Привлекательность такого подхода состоит в следующем.

Обеспечивается специализация. Каждый отдел выполняет ограниченный набор функций, что стимулирует эффективный обмен знаниями.

Практически не возникает дублирования, создаются условия для стандартизации как внутри информационной службы, так и снаружи.

Легче достигается эффективный масштаб, что особенно актуально для тяжеловесных решений на базе мэйнфреймов, и в меньшей степени, но все же важно, для клиент - серверных систем. Под эффективным масштабом подразумевается такой размер подразделений, при котором выполнение капиталоемких функций становится экономически целесообразным. Например, пять небольших подразделений, разрабатывая ПО в рамках своих скромных бюджетов, будут использовать дешевый Microsoft Access. Объединенное подразделение, располагающее объединенным бюджетом, может позволить себе использовать дорогой Oracle.

Руководитель Управления облегчает себе принятие решения об исполнителях по каждой новой задаче.

Недостатки функционального подхода также хорошо известны:

Возникают проблемы с комплексным обслуживанием клиентов (внешних подразделений), предоставлением разных услуг разным клиентам.

Страдают скорость и качество оказываемых услуг.

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

Недостатки функционального подхода частично нивелируются применением клиентской или продуктивной схемы.

Организация по клиентам

Организационная структура Управления в разрезе по клиентам могла бы выглядеть, например, таким образом:

Отдел производственных систем,

Отдел сбытовых и маркетинговых систем,

Отдел систем учета и отчетности,

Отдел делопроизводства и систем управления кадрами.

Клиентская схема организации обеспечивает:

Более качественное и быстрое обслуживание за счет ориентации на конкретные категории клиентов и даже отдельных клиентов.

Более полное удовлетворение клиента за счет детального знания его потребностей и внутренних особенностей.

Недостатками клиентской схемы являются:

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

Потеря экономии от масштаба.

Организация по продуктам

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

Отдел разработки и сопровождения системы X,

Отдел разработки и сопровождения системы Y,

Отдел разработки и сопровождения системы Z.

В этом случае помимо плюсов, характерных для клиентской схемы, возникает еще один - сокращение времени на разработку новых продуктов (систем).

Среди дополнительных минусов - проблема комплексного обслуживания клиентов по набору продуктов.

Дополнительно к перечисленным вариантам есть еще пара способов выстраивания первого уровня иерархии Управления:

По территориальному признаку,

По основным внутренним процессам.

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

Тем не менее, можно представить один из вариантов данного структурного решения, при котором информационная служба разделялась на две части: одна отвечала за развитие, другая – за сопровождение. И такой подход давал хорошие результаты.

Планирование и контроль проектных работ

Управление проектированием ИС в функциональном аспекте рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимаются действия и процедуры, связанные с решением конкретных задач или реализацией функций управления, к которым относятся:

Процессы инициации, связанные с принятием решения о начале выполнения проекта или какого-либо очередного этапа или фазы его;

Процессы планирования - совокупность процедур, связанных с определением целей и критериев успеха проекта и разработкой рабочих схем и достижения;

Процессы исполнения, предназначенные для координации людей и других ресурсов для выполнения плана;

Процессы анализа, дающие возможность определить соответствие плана и исполнения проекта поставленным целям и критериям успеха и принять решения о необходимости применения корректирующих воздействий;

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

Процессы завершения- процессы формализации выполнения проекта и составления отчетности.

Стратегическое планирование развития ИТ и ИС на объекте управления. Типы ИС и тенденции их развития.

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

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

Планирование,

Контроль исполнения плана,

Регулирование – анализ результатов и принятие решений.

Планирование

Как правило, существуют два типа планов автоматизации предприятия:

Стратегический план,

Оперативный план.

Крайне желательно, чтобы и стратегический, и оперативный планы были составлены в письменном виде. Отличие стратегического плана от оперативного состоит в следующем.

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

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

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

Контроль исполнения планов

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

В состав представляемой оперативной информации в обязательном порядке должна включаться информация о возникших по мере реализации плана проблемах.

Анализ результатов и принятие решений

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

Стратегический план

Стратегия автоматизации в первую очередь должна соответствовать приоритетам и стратегии (задачам) бизнеса предприятия. В понятие стратегии также должны входить пути достижения этого соответствия. Стратегический план автоматизации должен составляться с учетом следующих факторов:

Средний период между сменой технологий основного производства;

Среднее время жизни выпускаемых предприятием продуктов и их модификаций;

Анонсированные долгосрочные планы поставщиков технических решений в плане их развития: снижение доли нестандартизованных компонентов на всех уровнях (интерфейсы, контроллеры, операционная система и т.д.), расширение типов совместимых платформ; создание средств конвертации данных, систем архивирования; интеграция со смежными системами;

Срок амортизации используемых систем;

Стратегический план развития предприятия, включая планы слияния и разделения, изменение численности и номенклатуры выпускаемой продукции;

Планируемые изменения функций персонала.

Таким образом, стратегия автоматизации представляет собой план, согласованный по срокам и целям со стратегией организации.

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

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

Цели бизнеса:

Области деятельности предприятия и последовательность, в которой они будут автоматизированы;

Степень соответствия приоритетов автоматизации и стратегии бизнеса, а именно – целям, которые должны быть достигнуты:

Снижение стоимости продукции;

Увеличение количества или ассортимента;

Сокращение цикла: разработка новых товаров и услуг – выход на рынок;

Переход от производства на склад к производству под конкретного заказчика с учетом индивидуальных требований и т.д.

Стратегические цели бизнеса с учетом ограничений (финансовых временных и технологических) конвертируются в стратегический план автоматизации предприятия.

Способ автоматизации:

· по участкам,

· направлениям,

· комплексная автоматизация.

Долгосрочная техническая политика – комплекс внутренних стандартов, поддерживаемых на предприятии: типы стандартов на оборудование и ПО, перечень поставщиков и производителей базовых аппаратно-программных средств, на использование продукции которых ориентировано предприятие, перечень продуктов и линий продуктов, которые используются или которые предполагается использовать в области автоматизации;

Ограничения

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

Финансовые,

Временные,

Связанные с влиянием человеческого фактора,

Технические.

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

Временные ограничения обычно связаны со следующими факторами:

Сменой технологий основного производства,

Рыночной стратегией предприятия,

государственным регулированием экономики.

К ограничениям, связанным с влиянием человеческого фактора, относятся следующие:

Корпоративная культура – отношение персонала к автоматизации:

Особенности рынка труда:

Трудовое законодательство, регулирующее процессы увольнения персонала, высвобождающегося в результате автоматизации.

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

Особенности рынка труда могут повлиять негативно, если существуют трудности с наймом персонала требуемого профиля и квалификации.

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

Технологии

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

Интеграция нескольких существующих систем;

Разработка уникальной системы для предприятия;

Откладывание решения о начале работ по автоматизации в ожидании появления требуемой системы.

Проблемы

Типичные проблемы, которые возникают при разработке стратегии автоматизации, как правило, связаны со следующими факторами:

· состояние рынка информационных технологий;

· определение эффективности инвестиций в информационные технологии;

· необходимость реорганизации деятельности предприятия при внедрении информационных технологий.

Внедрение системы автоматизации управления является сложным и довольно болезненным процессом. В ходе возникает великое множество больших и малых проблем. Некоторые из них можно предотвратить или свести к минимуму, тем самым, повысив эффективность самой системы.

Отсутствие постановки задачи

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

Сопротивление сотрудников предприятия

При внедрении информационных систем очень часто возникает активное сопротивление сотрудников предприятия.(тихий саботаж)

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

В обыкновенном страхе перед всем новым.

В консерватизме.

Опасение потерять свою работу.

Повышение ответственности за свои действия.

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

Временное увеличение нагрузки на сотрудников

На некоторых этапах проекта внедрения временно возрастает нагрузка на сотрудников предприятия. Это связано с тем, что помимо выполнения обычных рабочих обязанностей, сотрудникам необходимо осваивать новые знания и технологии. Во время проведения опытной эксплуатации и при переходе к промышленной эксплуатации системы в течение некоторого времени приходится вести дела, как и в новой системе, так и продолжать ведение их традиционными способами (поддерживать бумажный документооборот и существовавшие ранее системы). В связи с этим, отдельные этапы проекта внедрения системы могут затягиваться под предлогом, что у сотрудников и так хватает срочной работы по прямому назначению, а освоение системы является второстепенным и отвлекающим занятием. В таких случаях руководителю предприятия, помимо ведения разъяснительной работы с уклоняющимися от освоения новых технологий сотрудников необходимо:

Повысить уровень мотивации сотрудников к освоению системы в форме поощрений и благодарностей;

Принять организационные меры к сокращению срока параллельного ведения дел.

Нецелесообразность собственных разработок

На многих крупных предприятиях существуют системы, разработанные в 80-90 гг. в операционной системе DOS. Часто эти системы были созданы силами специалистов АСУ предприятия.

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

Разработка программного обеспечения под Windows гораздо сложнее, чем под DOS.

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

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

Поэтому лучше выбрать автоматизированную систему управления предприятием, имеющую положительный опыт внедрения.

У программистов есть такая присказка, что внедрение системы как ремонт – его невозможно закончить, а можно лишь прекратить. Так что внедрение, по сути, никогда не закончится, потому что система должна постоянно расти, развиваться и совершенствоваться вместе со своим предприятием.

Классификация ИС

В зависимости от характера обработки информации в ИС на различных уровнях управления (оперативном, тактическом и стратегическом) выделяются следующие типы информационных систем:

Системы обработки данных (EDP – electronic data processing);

Информационная система управления (MIS – management information system);

Система поддержки принятия решений (DDS – decision support system).

Системы обработки данных (СОД) предназначены для учета и оперативного регулирования хозяйственных операций, подготовки стандартных документов для внешней среды (счетов, накладных, платежных поручений). Горизонт оперативного управления хозяйственными процессами составляет от одного до несколько дней и реализует регистрацию и обработку событий, например оформление и мониторинг выполнения заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д. Эти задачи имеют итеративный, регулярный характер, выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.) и связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных.

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

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

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

Развитием систем ППР являются экспертные системы (ЭС), использующие знания экспертов, представленные в некотором формальном виде. При этом используются базы обобщенной информации, информационные хранилища, базы знаний о правилах и моделях принятия решений.

Идеальной считается ИС, которая включает все три типа перечисленных информационных систем.

В зависимости от охвата функций и уровней управления различают корпоративные (интегрированные) и локальные ИС.

Корпоративная (интегрированная) ИС автоматизирует все функции управления на всех уровнях управления. Такая ИС является многопользовательской, функционирует в распределенной вычислительной сети.

Локальная ИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ИС может быть однопользовательской, функционирующей в отдельных подразделениях системы управления.

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

Одним из основных свойств ИС является делимость на подсистемы. Выделяют:

Функциональные подсистемы ЭИС, которые информационно обслуживают определенные виды деятельности предприятия, характерные для структурных подразделений и функций управления (управление производством, технико-экономическое планирование, бухучет и др.).

Обеспечивающие подсистемы ЭИС, которые играют вспомогательную роль по отношению к функциональным подсистемам: системного программного обеспечения, технического обеспечения, компьютерных сетей и обмена данными.

Делимость на подсистемы имеет ряд достоинств с точки зрения разработки и эксплуатации ЭИС, к которым относятся:

Упрощение разработки и модернизации ИС в результате специализации групп проектировщиков по подсистемам;

Упрощение внедрения и поставки готовых подсистем в соответствии с очередностью выполнения работ;

Упрощение эксплуатации ИС вследствие специализации работников предметной области.

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

Пути развития ИС

Трансформация информационных систем

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

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

Определение АСУ, данное в эпоху общегосударственного планирования и управления, имеет следующий вид: «Автомати­зированная система управления - это система, состоящая из пер­сонала и комплекса средств автоматизации его деятельности, ре­ализующая информационную технологию выполнения установ­ленных задач». Таким образом, АСУ разворачивались для того, чтобы предприятие могло быстрее и лучше выполнить спущен­ный сверху план. Этому в АСУ подчинено все. Причем и сами АСУ строились в значительной мере сверху, т.е. по отраслевым стандартам. Сейчас предприятие автономно в вопросах создания ИС.

Развитие АСУ может происходить и происходит по пути преобразования их в так называемые корпоративные информаци­онные системы (КИС). Хотя на первый взгляд это чуть ли не одно и то же на самом деле разница в них существенна настолько, что КИС можно трактовать как цель развития АСУ. Это следует из определения: «КИС объединяет бизнес-стратегию предприятия (с выстроенной для ее реализации структурой) и передовые ин­формационные технологии для реализации управленческой иде­ологии». Сравнивая определения АСУ и КИС, можно постичь разницу.

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

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

КИС призвана поддержать так называемый регулярный менед­жмент. Если на предприятии такового не существует (и нет попыток его наладить), КИС будет на фирме «инородным телом». В благоприятных случаях, когда высшее руководство фирмы реши­тельно настроено на создание управленческой ИС, на предприятии должны быть создана головная группа по созданию КИС, выделе­ны все необходимые ресурсы, предоставлены полномочия и обеспе­чена всерьез поддержка ее деятельности ресурсами, технологически и психологически на протяжении длительного времени.

Значительная роль в развитии ИС от АСУ в сторону КИС на любой фирме принадлежит также и службам автоматизации. Однако на отечественных предприятиях отделы АСУ были вспо­могательными, прямая связь между директоратом и службой АСУ, как правило, и сейчас еще разорвана. Исключение состав­ляют разве что некоторые банковские структуры. В связи с этим масштабные задачи с применением сложнейших технологий до сих пор возлагаются на малочисленные подразделения АСУ, воз­можности которых ограничены.

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

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

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

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

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

Если не согласовывать проект с изменяющимися условиями бизнеса, то КИС может устареть раньше, чем будет закончена. Конечно, разработка и внедрение КИС - это обычный большой проект, которому нужны бюджет и сметы и управлять которым следует с точки зрения финансового менеджмента. Вместе с тем стремительность происходящих изменений как в экономике в целом, так и (в особенности) в ИТ делает традиционное плани­рование неадекватным. Это не значит, что следует отказаться от планирования. Более того, информационные модели, базы опе­ративных данных позволяют рассмотреть различные варианты и выбрать подходящий. КИС, конечно, можно создавать и по час­тям, но только при наличии единого комплексного системного проекта, с тем, чтобы потери были сведены к минимуму.

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

Документация на систему должна быть не хуже самой систе­мы. Формирование документации позволяет обеспечить диаг­раммная техника представления управленческих процессов, на­пример IDEF-диаграммы (Intergrated DEFinition). Процессы описываются в виде функций, преобразующих входную инфор­мацию в выходную. С использованием количественных характе­ристик функций («стоимость», «длительность» и т. п.) возможно не только описывать, но и моделировать управленческие процес­сы и находить пути их оптимизации.

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

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

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

реализация любой подсистемы КИС должна предваряться созда­нием высокоуровневых, согласованных с заказчиком структур­ных схем и спецификаций. Важны логическая полнота специфи­каций и их прозрачность для понимания. Здесь нет мелочей: воз­никновение «диалектов» на информационном пространстве или отсутствие спецификаций по срокам хранения, размещению и архивированию информации быстро приводит к серьезным проблемам.

Особенности задач выбора платформ

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

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

По существу, это всегда важная и сложная проблема, кото­рую нужно решать при построении любых ИС самого различно­го назначения. Если же ставится задача более строго - обосно­вать оптимальность избираемых вариантов платформы, то ее постановка и решение требуют проведения достаточно объемных и наукоемких исследований (формирование моделей, определе­ние критериев оптимальности, а также проведение моделирова­ния, в ряде случаев достаточно трудоемкого). Единых рекомендаций по решению этих проблем не существует. Одни фирмы используют эффективные варианты систем, в которых за счёт переноса основных операций с центральной машины на рабочие места повышается степень распараллеливания вычислительного процесса. Другие, напротив, отдают предпочтение консолидированным центральным системам, обеспечивающим распараллеливание процессов за счёт лучшего управления и при этом высокую степень информационной защищённости.

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

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

В этих условиях сведение проблемы к выбору между просто центральной и распределенной системой также не отражает си­туации во всей ее полноте. Так, по данным аналитической компании ITG, центральная система на базе мейнфрейма IBM ES/9000 с сетью из 50 и более IBM PC имеет явные преимущества перед распределенной: сред­няя полная стоимость одного рабочего места пользователя ПК в этой системе ниже примерно в 2 раза, а средняя полная стоимость транзакции примерно в 7-10 раз ниже, чем в сети.

Сплошное разукрупнение осталось позади, и идет уже обрат­ный процесс. Признано, что централизованное обслуживание компьютерных ресурсов при большом числе пользователей эко­номически выгоднее распределенного. По данным компании ITG, для финансовых систем расходы на одного пользователя в год при децентрализованной системе на базе UNIX-серверов состав­ляют 11,6 тыс. долл., при использовании одного UNIX-сервера -4,9 тыс. долл., а мейнфрейма IBM S/390 - 3,4 тыс. долл. (это отно­сится к уровню в 500 пользователей; при 1000 пользователей преимущество S/390 еще больше возрастает).

По данным отдела больших систем компании «IBM Восточ­ная Европа», при росте числа пользователей в распределенной системе стоимость одного рабочего места возрастает, а в центра­лизованной, напротив, падает. К тому же выпуск новых процес­соров приводит к снижению стоимости 1 MIPS: в начале 1999 г. эта цена в разных системах составляла уже 5-6 тыс. долл. и все более снижается. Это приводит к соответствующему снижению порогового числа рабочих мест, при котором содержание одно­го рабочего места в системах на базе мейнфрейма S/390 оказыва­ется меньше, чем в распределенной системе, и применение мейн­фрейма становится выгоднее. Эта граница в начале 1999 г. про­ходила на уровне 100 рабочих мест.

Стоимость электронной почты в год на одного человека при числе пользователей от 1 до 5 тыс. составляет в децентрализо­ванных системах на базе Windows NT 287 долл., в централизо­ванных системах на базе NT - 149 долл., на базе ОС UNIX -116 долл. и на базе S/390 - 88 долл. Общая стоимость владения (ТСО) за год в расчете на одного пользователя, работающего с прило­жениями оперативной обработки транзакций при централизован­ном обслуживании UNIX-серверами, составляет почти 5,5 тыс. долл., а для мейнфреймов - около 3,1 тыс. долл. Распределенные системы на базе Windows NT менее экономичны.

Правда, пытаясь применить эту статистику к российским ус­ловиям, нужно вспомнить об отечественной специфике. Здесь в первую очередь следует учесть относительно более низкий уро­вень оплаты труда в нашей стране, в то время как стоимость тру­да в «американской» оценке вносит определяющий вклад в об­щие затраты при большом числе пользователей. Многие другие статьи затрат тоже связаны с уровнем оплаты труда в отрасли. И все же стремление к централизации налицо. Так, в марте 2000 г. установлен суперсервер SUN Enterprise 10 000 в управлении Ми­нистерства по налогам и сборам по Москве. Он включает:

– 16 процессоров Ultra SPARC 400 МГц;

– 8 Гбайт оперативной памяти;

– основной дисковый массив StorEdge A 5200 объемом 127 Гбайт;

– операционную систему Solaris 7;

– СУБД Oracle 8.1.

К подсистеме «Единый государственный реестр налогопла­тельщиков» подключаются около 4 тыс. пользователей.

Семинар, прошедший в 2000 г. в Красноярске, показал, что в этом крае заказчики проявляют интерес к системам даже более стар­шим, чем RISC-серверы, например к платформам AS/400 и S/390.

В то же время явно сохраняется и тенденция разукрупнения систем. Однако потребность высшего руководства системы в ее высокой защищенности и управляемости из центра не может быть удовлетворена дешевыми и доступными системами на основе ПК и приводит к выбору систем на основе UNIX- или более мощных архитектур, характерных для средних машин (например, IBM AS/ 400), или даже мейнфреймов (например, IBM ES/9000).

Разработка стратегии «клиент-сервер» представляет собой стремление совместить достоинства обоих подходов: при нали­чии мощных средств на рабочих местах иметь управляемую и защищенную систему в целом. На этом пути также имеются не­которые особенности.

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

В этих условиях на предприятии, которое собирается приоб­рести новое «клиент-серверное» приложение, возникает вопрос:

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

Другим важным фактором в этих условиях является необхо­димость учета перспективы развития системы. По мере постанов­ки задач пользователями возрастают потребности в ресурсах и система нагружается выше ее номинальных параметров, снижая качество работы. На практике многие требования могут эффек­тивно удовлетворяться как мощными моделями ЭВМ низшего класса, так и маломощными моделями высшего ряда ЭВМ: на­пример, мощным PC или UNIX-машиной, UNIX-машиной или AS/400; AS/400 или ES/9000. Как правило, все семейства машин допускают существенное наращивание ресурсов (производитель­ность. емкость памяти, число процессоров) внутри себя, называ­емоемасштабированием, что всегда дешевле смены платформы. Это позволяет системе существовать достаточно продолжитель­ное время в пределах одной платформы.

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

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

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

– создание единого мирового рынка информатизации;

– исчезновение границ в деятельности компаний;

– постоянное развитие технологической базы всех составляющих системы, взаимное проникновение различных технологий;

– отсутствие резких границ между секторами производства:

– используются одни и те же базовые элементы, програм­мные и информационные средства соответственно совместимы и т.д.;

– стирание границ между фирмами (многочисленные корпора­тивные проекты, совместные предприятия, слияние и взаимное прорастание фирм, частичное участие в капиталах);

– «отрицание отрицания»: создание и введение новых продук­тов с лучшими характеристиками в значительной мере под­рывают интерес к тем, которые еще продаются. Таким образом, основные составляющие ИТ - операционные среды, системы работы с данными, средства создания приклад­ных программ и комплексных прикладных систем, а также вы­числительные средства - обеспечивают создание живучих структур, допускающих всестороннее развитие.

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

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

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

Рис Последовательность задач организационного проектирования системы управления

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

2. Организационное моделирование развивается как в научно-теоретическом плане, так и в направле­нии, носит прикладной характер и может охватывать различные аспекты при формировании структуры уп­равления: управленческий, информационный, соци­ально-психологический. Это создает возможность для комплексного рассмотрения вопросов, стоящих на пу­ти решения проблемы, начиная с расчета количествен­ных параметров и кончая организационным регламен­тированием подразделений.

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

Таким образом,метод организационного моделирова­ния является наиболее универсальным и современным для проектирования организационной структуры и процессов принятия решений.

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

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

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

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

Рис. Этапы проектирования системы управления методом организационного моделирования

Навтором этапе осуществляется распределение управленческих решений по уровням в рамках матрично-штабной структуры.

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

где Qp - суммарная трудоемкость, ч.

Тi - трудоемкость i -го управленческого решения, ч.;

Кij - число повторений i -го решения на j-м уровне;

где Ср - расчетное число руководителей;

Qp - трудоемкость принятия управленческих решений, ч.;

Fд - действенный фонд времени одного сотрудника, ч

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

Рассмотрим, как решается вопрос о выборе вариан­та структуры в зависимости от загрузки уровней управ­ления. Расчет загрузки начинается с линейного уровня, поскольку он присущ любой структуре управления и в определенном смысле является доминирующим. Иссле­дования показали, что переход к проектированию той или иной формы организации управления зависит от величины загрузки линейного уровня, которая может быть меньше установленного предела, находиться в за­данных границах предела (К 1 <Ср <К 2 ) и выходить за эти границы.

(Ср> К 2), где Ср - расчетная величина загрузки,

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

Случай 1. Загрузка линейного руководителя меньше установленного предела, т.е. Ср < К1. Алгоритм выбора в данном случае заключается в поэтапном объединении уровней, присущих матрично-штабной структуре, с ли­нейным уровнем в целях обеспечения загрузкой линей­ного руководителя. Объединение начинается с коорди­нирующего уровня, так как процесс трансформации матрично-штабной структуры в любую другую начинает­ся с исключения именно этого уровня. Если на первом шаге процесса загрузка не достигается, добавляется те­матический уровень, а затем при необходимости и функциональный. При таком соотношении, когда за­грузка линейного руководителя складывается из объеди­ненной загрузки руководителей координирующего, тема­тического и функционального уровней, т.е. Ср = Сл, +Ск + +Ст , + Сф, возможно проектирование только линейной структуры управления. В остальных случаях, когда на­грузка линейного руководителя достигается на первом шаге итерации, т.е. Ср = Сл + Ск; либо на втором: Ср = = Сл+Ск+Ст создается возможность проектирования линейно-функциональной либо матричной структуры управления. Следовательно, при недостаточной загруз­ке линейного уровня в зависимости от исходных рас­четных данных и функционального, тематического и координирующего уровней можно проектировать три варианта структуры: линейную, линейно-функцио­нальную и матричную.

Случай 2 . Загрузка руководителя линейного уровня находится в установленных границах предела К1>Ср <К2. В этом случае информация о линейном уровне является достаточной и выбор варианта структуры будет зависеть только от соотношения загрузки последующих уровней. Если загрузка достигается на всех уровнях, происходит выбор матрично-шаблонной структуры управления, при любых других условиях выбирается линейно-функцио­нальная или матричная структура.

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

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

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

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

Номенклатура руководителей и исполнителей (со­ставляется на основании штатного расписания);

Сведения о трудоемкости принятия и подготовки управленческих решений (получены в результате экспертного опроса);

список решений закрепленных за:

линейным уровнем управления;

функциональным уровнем управления;

тематическим уровнем;

координационным уровнем;

Эффективный фонд времени руководителей и ис­полнителей.

Расчетное число исполнителей определяется по сле­дующей формуле:

где Сисп - число исполнителей, обеспечивающих подготовку управленческих решений;

Qисп - трудоемкость подготовки i -х решений, ч.;

Fд - действительный фонд времени одного исполнителя, ч.

После того как будет рассчитано число исполнителей и руководителей на каждом уровне, решается вопрос о создании структурных подразделений. Это достигается путем корректировки полученной численности. Все дан­ные, необходимые для этого, имеются: расчетное число руководителей и исполнителей, типовая схема организа­ции управления (в данном случае - схема матрично-штабной структуры); допустимая норма управляемости для заданного объекта. Корректировка полученной чис­ленности происходит следующим образом. Определяется принятое число руководителей и исполнителей путем округления расчетного числа и проверяется норма уп­равляемости. Если полученное соотношение значительно превышает норму управляемости, решается вопрос о соз­дании дополнительного органа управления (если сохраня­ется возможность разделения функции управления). И наоборот, при сниженной норме управляемости два ор­гана управления, выполняющие смежные функции, мо­гут быть объединены в один. Так, с учетом типовой схе­мы управления происходит формирование структурных подразделений. Итоговыми документами этого этапа ра­боты являются скорректированные списки исполнителей и руководителей по подразделениям, а следовательно, и состав подразделений на каждом организационном уровне.

Нашестом этапе принимается решение о внедрении данной структуры и утверждении схемы управления.

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

Важной задачей является проектирование комплек­са процедур принятия решений (ППР) (блок 7). Про­диктовано это тем, что организационная процедура является одним из основных элементов технологии управления, определяет последовательность этапов ра­бот, которые в итоге регламентируют процесс управ­ленческого труда. Иными словами, организационная процедура - это комплекс взаимосвязанных техноло­гических операций, направленных на достижение чет­ко фиксированной цели. Примерами процедур могут служить: «составление отчета о проделанной работе», «оформление командировочного удостоверения», «офор­мление сотрудника на работу» и др. Имея полный перечень процедур, принимаемых в отделе, можно соста­вить схему принятия решений, которая позволит су­дить об эффективности функционирования отдела. Как это сделать практически мы покажем в главе 8. Кроме того применение метода организационного моделиро­вания на этой стадии процесса позволяет на основе полного перечня процедур смоделировать правила ра­бот исполнителей и руководителей в каждой процеду­ре, а затем и по отделу в целом.

Завершается весь процесс проектирования структуры управления разработкой положения об организации. Реа­лизация этого этапа требует всестороннего изучения и дополнения ряда положений (документов), обусловлен­ных требованиями хозяйственного законодательства, та­ких как: положение о предприятии, положение об отде­лах, должностные инструкции.

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

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

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

В первом случае – это связи запирающие продажи как в примере с ботинками когда отсутствие левых полупар запирает продажи правых а во втором – сопутствующие то есть их у вас покупают и по отдельности когда одного из товаров нет однако если есть оба то обычно покупают вместе. Мы взяли в качестве параметра – количество чеков или накладных однако часто бывают случаи когда товары являются сопутствующими при небольших количествах покупки но не являются таковыми на больших партиях. Пары с маленьким значением этого...

Поделитесь работой в социальных сетях

Если эта работа Вам не подошла внизу страницы есть список похожих работ. Так же Вы можете воспользоваться кнопкой поиск

Лекция 6. Проектирование эффективной системы управления товарными запасами

Возьмем простой пример: по отдельности вы не продадите ни один левый ботинок, ни один правый, – однако вместе их у вас купят целую партию. Для логистов важен не столько маркетинговый эффект, сколько обнаружить подобные « наборы » в менее явных случаях, и в каком соотношении их держать на складском остатке . Благодаря такой информации можно уточнить стратегии эффективного продвижения товаров в готовых наборах, например, установки небольшой наценки на основной товар, окупающейся хорошей наценкой на сопутствующие. А так как сотрудники каждого из отделов наиболее осведомлены в своей области, то наиболее эффективно, осуществлять поиск групп соответствующих товаров общими усилиями.

Прежде всего, надо обратить внимание на две различные ситуации « товарных наборов » . В первом случае – это связи, запирающие продажи , как в примере с ботинками, когда отсутствие левых полупар запирает продажи правых, а во втором – сопутствующие, то есть их у вас покупают и по отдельности, когда одного из товаров нет, однако, если есть оба, то обычно покупают вместе. Так же важно понять, что связь может быть как двусторонней, как в примере с ботинками, так и односторонней, например, в цветочном магазине отсутствие цветов запирает продажи упаковочных материалов, но не наоборот, по крайней мере, не в той же мере.

Обнаружить сопутствующие товары интересующей нас позиции очень просто – для этого надо проанализировать, насколько часто они продавались вместе по отношению ко всем продажам этой позиции.

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

Анализировать товары можно попарно. Если у вас есть наборы сопутствующих товаров, состоящие из большего количества наименований, – они выявятся через парные связи. Другая ситуация в случае наличия агрегированной зависимости, хорошим примером которой является как раз продажа цветов и упаковочных материалов, – не имея зависимости между продажами конкретных цветов и конкретной упаковки, мы получим очень жёсткую запирающую связку между всеми цветами и всей упаковкой.

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

Мы взяли в качестве параметра – количество чеков (или накладных ) , однако часто бывают случаи, когда товары являются сопутствующими при небольших количествах покупки, но не являются таковыми на больших партиях. Поэтому, если компания торгует одновременно и крупным, и мелким оптом, да ещё и в розницу, тогда при агрегированном анализе сопутствующих товаров, в качестве параметра лучше брать количество проданных единиц каждого товара в общих и раздельных чеках, а не количество самих чеков – по сути разных.

В качестве примера можно взять пивной ларёк, который торгует разливным пивом одного вида (П ) и двумя видами закуски к нему: вяленой воблой (В ) и вяленой чехонью (Ч ) . Рассмотри все чеки на предмет, товаров попавших в один чек, не рассматривая их количества в нём. Проанализировав чеки, мы понимаем, что воблу и чехонь всегда берут с пивом, то есть K ВП = K ЧП = 1, однако пиво берут с воблой только каждый второй раз, поэтому: K ПВ = 0,5 ; а с чехонью только три раза из десяти: K ПЧ = 0,3 ; два раза из десяти пиво берут вообще без какой-либо рыбы. А вот чехонь и воблу вместе не берут, следовательно: и K ВЧ = 0, и K ЧВ = 0.

Но вернёмся к нашему отсеиванию пар по их коэффициенту К. Пары с маленьким значением этого коэффициента нас не будут интересовать, так как для таких пар обычно принято в качестве такого уровня брать значение 0,8, однако редко когда в качестве такого уровня берут значение больше 0,9 или меньше 0,7.

В примере с пивным ларьком мы отбросили все пары, кроме воблы с пивом (К ВП = 1 ) и чехони с пивом (К ЧП = 1 ) , так как только они были больше 0,7. Однако, вспомнив то, что говорили в самом начале про влияние агрегированных групп, рассчитаем ещё коэффициент совместных продаж пива и рыбы вообще – и чехони, и воблы вместе взятых (Р ) : К ПР = 0,8. В данном случае он получился равным сумме К ПВ и К ПЧ , однако обычно эти коэффициенты – не аддитивны, то есть их нельзя складывать. В нашем случае можно, так как воблу и чехонь ни разу не брали вместе, иначе нам пришлось бы просматривать опять все чеки на предмет одновременной продажи пива и какой-либо рыбы вообще. А так как К ПР получился больше 0,7, то мы тоже берём его в дальнейший расчёт коэффициентов запирания продаж.

Запирающие товары по неравенству выше – являются заведомо сопутствующими, поэтому искать мы их будем именно среди них . Однако обратной такой однозначной зависимости нет. В большинстве случаев возможен экспертный анализ – как в примере с цветочным магазином, когда зависимость продаж упаковки (У ) от наличия цветов (Ц ) – очевидна. В таких случаях, то есть при отсутствии на остатках цветов, продаж упаковочного материала можно не ожидать.

Фактически мы берём отношение средних продаж основного товара за день, когда сопутствующего товара не было на складе, к средним продажам основного товара за день вообще. Это необходимо, так как количество таких дней – обычно разное.

Если в вашей компании практикуется разбиение номенклатуры товара на группы A , B и C с применением к товарам из разных групп разных методов пополнения остатка, в том числе и одинаковые методы с разными нормативами, а в результате вашего анализа оказалось, что товар M из группы C запирает продажи товара N из группы A – то необходимо включить оба товара в одну группу. Обычно в таком случае товар M включают в группу A – не как дающий большой вклад, а как стратегический.

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

В результате мы получаем скорректированный прогноз продаж товара M .

Соответственно, применения эту методику, мы купим достаточное количество: когда запирающий товар на складе будет – благодаря корректировке предполагаемых продаж в прошлом ; и не будем покупать лишнего, когда запирающего товара на складе не будет – благодаря корректировке прогноза продаж для расчёта будущих продаж.

Отдельно надо оговорить сложные случаи, когда продажи одной и той же позиции M запирают отсутствием свободного остатка сразу две и более позиций, например: N 1 и N 2.

Если есть такая возможность, то лучше оценить его отдельно по агрегированной группе всех запирающих позиций – как в примере, когда продажи пива запираются отсутствием на свободном остатке любой рыбы. Если такой возможности нет, например, когда запирающие позиции не являются аналогичными, как вяленая вобла и вяленая чехонь, то остаётся только оценить это состояние по последнему отдельным позициям на свой страх и риск. Однако при такой оценке вам надо учитывать, что чем более позиции N 1 и N 2 зависимы друг от друга, тем ближе искомый коэффициент в неравенстве будет к максимуму, а, чем более независимы, – тем ближе к сумме.

Другие похожие работы, которые могут вас заинтересовать.вшм>
2038.		Политика цен в сбытовой логистике как способ управления товарными запасами	14.75 KB
	Политика цен в сбытовой логистике как способ управления товарными запасами Способы образования базисной цены продукции: свободное установление цен. Такой способ установления цены применяется при сбыте например нестандартной продукции; применение прейскурантной цены. При назначении прейскурантной цены учитываются следующие факторы характеризующие конкретных потребителей: принадлежность покупателя к определенному сегменту рынка; количество закупаемой продукции; возможность дополнительных заказов; наличие у потребителя...
2347.		Управление товарными запасами торгового предприятия	15.84 KB
	На одном из них назовем его микроуровень можно говорить о вопросах связанных с оптимизацией процедур обработки заказа всеми задействованными сотрудниками предприятия –от его оптовых сэйлов до персонала складского комплекса. При решении задач этой области нам предстоит организовать управление товарными запасами так чтобы в заказах поставщикам учитывались запланированные отгрузки клиентам. На разных предприятиях есть свои особенности но надеемся описанная схема поможет читателю в общих чертах представить механизм закупки...
2332.		Различные подходы к управлению товарными запасами	23.2 KB
	Различные подходы к управлению товарными запасами Управление товарными запасами имеет серьезное значение в управлении торговым предприятием. Следовательно для эффективного управления торговым предприятием прежде всего необходимо использовать оптимальную модель управления товарными запасами. Нерациональное управление запасами предприятия часто приводит к большим экономическим потерям. Эффективное решение проблем управления товарноматериальными запасами требует использования соответствующих методов.
2036.		Управление товарными запасами оптовых предприятий	19.39 KB
	Создание товарных запасов всегда требует определенных финансовых вложений и поэтому их величина отражает реальные финансовые возможности накопления товаров. В основе создания запасов на торговых предприятиях лежат факторы экономического организационно технологического и социального характера. В условиях рынка существует много причин почему фирмы идут на создание запасов. При этом особого внимания заслуживает соотношение запасов и потоков которое поддается управленческим воздействиям и несомненно влияет на изменение нормы прибыли.
2335.		Системы управления запасами	17.39 KB
	Расходы в системе управления запасами Критерием оптимизации запасов являются общие расходы на выполнение заказов и хранение материалов. В системе закупки и хранения материалов расходы делятся на следующие группы: расходы на выполнение заказа; прямые расходы определяемые закупочной ценой; расходы на содержание запасов; издержки дефицита. Расходы па выполнение заказа связаны с размещением и поставкой заказа. К их числу относятся такие статьи расходов как стоимость разработки условий поставки и их подготовка к утверждению; расходы...
20601.		Совершенствование системы управления запасами OOO «Адидас»	1.84 MB
	Теоретические основы системы управления запасами торговой компании. Основные направления совершенствования системы управления запасами. Анализ лучших практик в области совершенствования системы управления запасами торговых компаний. Процедура совершенствования управления запасами...
12247.		Анализе системы управления запасами на предприятии (ОАО «БФ Коммунар»)	352.3 KB
	Запас необходим для того чтобы не остановился производственный процесс что особенно важно для предприятий с непрерывным циклом производства. Особенно это важно для предприятий с непрерывным процессом производства так как в этом случае остановка производства может обойтись слишком дорого. Они...
20543.		Совершенствование системы управления запасами торговой компании	1.84 MB
	Основоположником успеха работы торговых компаний становится способность реагировать на изменения потребностей клиентов при обеспечении надлежащего сервиса. В связи с чем особенное внимание уделяется точности прогноза на этапе закупки. Разумеется, чтобы достичь высокой точности прогноза, необходимо выстроить процесс по планированию множества операций, начиная с этапа производства и согласования заказов с фабриками и заканчивая доставкой товаров до конечных потребителей.
15809.		Совершенствование системы управления запасами на основе применения логистических и информационных технологий на примере деятельности ОАО «БФ «Коммунар»	352.3 KB
	В этом случае запас необходим для того чтобы не остановился производственный процесс что особенно важно для предприятий с непрерывным циклом производства. Особенно это важно для предприятий с непрерывным процессом производства так как в этом случае остановка производства может обойтись слишком дорого...
5557.		Проектирование системы управления в организации (на примере гостиничного комплекса «Alexandros Palace Hotel&Suites»)	84.56 KB
	Данная курсовая работа посвящена теме Проектирование системы управления в организации гостиничного комплекса lexndros Plce HotelSuites Актуальность данной темы заключается в том что вопрос проблемы проектирования системы управления в организациях поднимается очень часто и этой проблеме необходимо уделять большое количество времени. Цель курсовой работы спроектировать систему управления в гостиничном комплексе lexndros Plce HotelSuites на основе анализа его...