Подборка учебно-методических материалов по теме «Внедрение СМК» (стр. 22 )

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

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

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

Главная цель организационного программирования - довести функции поддерживаемые в компании до конкретного человека. Чтобы на вопрос - "Кто это делает?" не следовал ответ - "Мы", а звучал бы ответ - "я". Наличие точных и реальных регламентов деятельности решает еще одну актуальную задачу Ц компания перестает быть <заложником конкретных сотрудников>, созданные регламенты позволят достаточно просто подключать к деятельности компании новых специалистов.

Реинжиниринг должностных инструкций

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

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

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

Схема 2. Типовая структура должностной инструкции

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

1. Точное наименование должности и место сотрудника в компании - в этом разделе устанавливается прямая и функциональная подчиненность сотрудника, замещение по должности и т. д. 2. Целевое назначение должности - дает представление об уникальном (или, по крайней мере, четко обособленном) вкладе сотрудника в достижение целей Компании (Группы), а также определяет общий характер работы и соответственно, выполняемых им функций 3. Функциональные обязанности - конкретные операции, возложенные на сотрудника и/или форма участия в их реализации

Пример (условный): Целевое назначение должности Управление качеством в компании. Функциональные Обязанности: Распределение работ по разработке, внедрению и поддержанию системы качества; Определение ответственных за выполнение работ; Анализ результатов по внедрению системы качества; Информирование руководства о состоянии работ; о неисполнении отдельными подразделениями/ сотрудниками взятых на себя обязательств по их выполнению; Методическое руководство созданием системы качества и т. д.

4. Взаимодействие по должности - включает в себя наименования Служб, видов взаимодействия (получение / предоставление информации), а также перечень вопросов, по которым происходит обмен информацией 5. Полномочия и Права - на доступ к ресурсам компании и связанных с распорядительными функциями и принятием решений 6. Ответственность - устанавливаемая необходимость отвечать за свои действия в рамках зафиксированных ранее обязанностей, прав и полномочий 7. Критерии оценки деятельности - для <доходоприносящих> должностей вытекают из показателей характеризующих достижение определенных целей, по <затратоприносящим> должностям - процедурные критерии. 8. Регламенты - документы, которыми сотрудник должен руководствоваться в своей текущей деятельности.

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

Часто, в Инструкцию помещают и требования к персоналу. Такие сведения, особенно, личностные требования, по сложившимся стандартам управления, включаются в специальные внутренние документы типа <Описание должности> (или <Описание рабочего места>), которые не показываются сотрудникам и служат руководством для кадровых служб при поиске и отборе персонала на вакантные должности. Однако, до поры до времени, допустимо и совмещение этих документов.

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

12. Об оценке эффективности внедрения и применения систем управления ресурсами предприятия

Сергей Колесников

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

Особую пикантность ситуации придает тот факт, что в западной практике этот же вопрос, активно обсуждавшийся 4-5 лет назад, в настоящее время практически "закрыт", будучи сведен к простой формуле, связывающей обороты компании и уровень затрат на создание системы управления ресурсами: (стоимость СУР)=(0.01-0.03)х(годовой оборот компании). К ней мы вернемся в конце статьи.

Из чего складывается стоимость типичного проекта внедрения?

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

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

Второй обязательной компонентой стоимости является цена программного обеспечения СУБД, на базе которой работает система управления. Здесь вариаций очень много, в целом принципы лицензирования аналогичны описанным выше, но допускаются всевозможные варианты: стоимость включается в стоимость лицензий основного ПО, или не включается, имеется специальная цена или фирменные скидки или нет. Если СУР многоплатформенная, то для разных СУБД принципы определения стоимости могут быть разными и более того, какое-то ПО придется покупать отдельно. Если СУБД "входит в поставку" СУР, то нелишне будет выяснить, какие еще компоненты СУБД могут потребоваться в ходе проекта: например, рабочее место программиста-разработчика, серверные компоненты для администрирования, компоненты для русификации или печати русских отчетов. Они могут не входить в стоимость стандартной поставки. Также нужно выяснить сможете ли вы использовать полученные лицензии СУБД для самостоятельно разработанных на ее базе продуктов и кто отвечает за сопровождение и поддержку поставленной СУБД: поставщик СУР или российский представитель фирмы-разработчика СУБД. То, что в любом случае отвечает последний - неверно!. Некоторые программные продукты продаются со встроенными СУБД, в этом случае отдельно лицензии на СУБД вообще не продаются. Однако это должно быть явно указано в контракте.

Заключает первую триаду стоимость поддержки и сопровождения ПО СУР и СУБД. Она обычно составляет 15-20% от их суммарной полной стоимости по контракту, за годичный период сопровождения, и включает в себя такие компоненты как "горячая линия" - поддержка по телефону, бесплатная поставка новых релизов и версий программного обеспечения, ответы на письменные запросы клиента, бесплатное устранение обнаруженных ошибок, и, возможно, ряд других условий. В договоре должны быть четко определены термины и порядок оказания всех перечисленных услуг, иначе потом вряд ли удастся доказать, что вы об этом договаривались. Особенностью российской специфики является частые изменения бухгалтерского и налогового законодательства, которые для своей реализации могут потребовать существенного вмешательства не просто в отчете формы, но и в бизнес-логику продукта. Такого рода изменения могут не попадать под условия стандартного договора о сопровождении даже отечественных производителей.