Программы для управления производством 2

Л.Точилов

1 2 3

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

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

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

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

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

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

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