sistemnii_analiz_v_ypravlenii_V (998781), страница 16
Текст из файла (страница 16)
- «CALS»-концепция, которая позиционируется как управление жизненным циклом. Однако, во-первых, пока нет даже устоявшейся дешифровки этой скорее модной аббревиатуры – в одних случаях ее происхождение прослеживается от англ. «Computer-Aided Logistic System» (системы управления логистическими или доставочными операциями), а в других усматривается родство с англ. «Continuous Acquisition and Life cycle Support». Судя по аббревиатурно пропущенным во второй версии словам, первый вариант все-таки исторически старше, первичнее. Однако ныне доминирует второй, в который в содержательном плане в основном привносится смысл первого и фрагментарно включается все остальное как дань приверженности современным тенденциям – начиная от штриховой маркировки продукции и кончая чертежными номерами для CAD-технологий. К сожалению, пока эта концепция имеет продуктивное начало в основном в части настолько позитивного, насколько и банального постулата, гласящего, что следует управлять парком продукции на всех этапах его жизненного цикла. При́нципного, процедурного, терминологического и инструментального обособления CALS-технология, судя по всему, пока не получила. В последнее время отмечаются попытки именовательного развития CALS-технологий и перехода на PLCS-технологии (от англ. Product Life Cycle Support);
- «WF»-концепция (от англ. «Work Flow» – поток работ, т.е. технологических операций общего вида), которая увязывается с таким направлением, как управление проектами, или, скорее, управление реализацией проектов. По своему смыслу она наиболее созвучна с общеизвестной технологической организацией производства (в том числе НИР и ОКР);
- «CF»-концепция (от англ. понятия «Cash Flow» – поток наличности, т.е. денежных средств), которая представляет собой ни что иное, как интерпретацию всех процессов через перемещение стоимостных эквивалентов. Эта концепция наиболее широкое практическое воплощение получила через бизнес-планирование. Однако в силу своей оболочечной надстроенности основную часть управленческих сфер она не покрывает, а оптимизация управленческих решений для большинства доступных программных сред бизнес-планирования просто не предусмотрена;
- «PC»-концепция (от англ. «Profit Center» – центр прибыли). Эта концепция в последнее время была «продвинута» ее приверженцами до дополнения понятиями центр убытков и центр ответственности. Управленческий смысл ее достаточно аморфен, а практические результаты алогичны – реалии российской действительности неизменно объявляют центрами прибыли директора и бухгалтерию, а центрами убытков – все основное и вспомогательное производство;
- «BP»-концепция (от англ. «Business Process» - бизнес-процесс). В рамках этой концепции любое организационно-экономическое обособление (например, предприятие, или корпоративная структура) представляется в глоссарных конструкциях некоей системы массового обслуживания общего вида, включающей подсистемы массового обслуживания, связанные между собой и с внешней средой материальными, денежными и информационными потоками требований. Нарицательность уточнения «бизнес» является концептуально необъяснимой, т.к. при осуществлении производственно-хозяйственной деятельности ни одно управленческое воздействие не может не повлечь за собой или возникновения доходов, или издержек, или и того, и другого, вместе взятого, а, следовательно, не может для организационно-экономического объекта существовать в природе процессов, которые не являются «бизнес»-процессами и не изменяют размеров прибыли, соотносимой с интерпретацией деятельности как предпринимательской. Однако, очевидно, что в случае заведомой пустоты одной из двух классификационных категорий сама такая классификация становится алогичной и поэтому не должна производиться. На самом деле эта концепция в лучшем случае является глоссарно искаженным аналогом концепции структурно-процессной идентификации производства, подлежащей применению при технологической организации производства на базе концептуальной схемы технико-экономического обоснования управленческих решений, но в привязке к организационным обособлениям – например, на внутрифирменном уровне – к структурным подразделениям предприятия. В этом смысле в рамках этой концепции организационное обособление (например, предприятие) как объект управления подвергается повторному именованию и тем самым искусственно позиционируется как новый;
- «Net»-концепция (от англ. «net» – сеть), предусматривающая только полный переход на глобальную сетевую схему информационного трафика, а также, возможно, схему «тонкого» клиента, предполагающую концентрацию инструментальных средств и получения к ним абонентского доступа со стороны пользователей-управленцев.
Нередко предлагается принять позицию “процессного” подхода, что подразумевает не что иное, как рассмотрение динамики состояния объекта управления.
Создается впечатление, что основная часть указанных концепций продвигается производителями баз данных и сетевых решений исключительно в интересах инициирования искусственного спроса на свои новые продукты.
Отечественные концептуальные прототипы управляющих систем – это некоторые гибриды, сочетающие преимущественно «SAP»- и частично «WF»-концепции, причем выполненные на примитивном уровне.
В связи с отсутствием концептуального прототипа соответственно отсутствует и инструментальный прототип.
Поэтому единственный продуктивный вариант проектного решения по концептуальной базе – первичное проектирование всех управляющих систем на базе «DSS»-концепции (от англ. «Decision Support System»), предусматривающей строгую формализацию управленческой задачи и ее иерархическое декомпозирование в сочетании с применением развитого инструментария технико-экономического обоснования управленческих решений. Для ускоренного проектирования таких DSS-систем необходимо создать или импортировать CASE-среду разработки управляющих систем (по крайней мере, на уровне CASE-продуктов, предлагавшихся, в частности, на российском рынке McDonnell Douglas Information Systems) и создать типовые управляющие системы для типовых сфер управления.
Второе методологическое решение касается выбора разработчика и способа развития. Предлагается выбрать на тендерной основе базового разработчика и заказать ему на пуловой основе или даже за счет средств федерального бюджета разработку базовой версии управляющей системы, которую затем развивать по Linux-схеме (маятниковое обновление стабильных и нестабильных ядер с открытым кодом). Ценовые параметры этого проекта для уровня предприятий едва ли выйдут с учетом возможности косвенного заимствования информационных моделей зарубежных управляющих за неприемлемые границы. Делать это можно также частично и за счет привлечения средств иностранных заказчиков, заинтересованных в организации оффсетных программ, фирменного обслуживания, лизинга, а также качественного послепродажного обслуживания;
Третье методологическое решение связано с характером распространения созданных управляющих систем. Несомненно, что классическая схема индивидуальной поставки управляющей системы не даст заметных позитивных результатов. Единственный вариант практически мгновенного подсоединения всех лиц, включая дислоцированные в отдаленных точках предприятия – применение схемы «тонкого клиента» и переход на виртуальную управляющую систему. Это должно быть также совмещено с созданием единого национального информационного пространства – формирования интегрированной защищенной инфосферы.
Четвертое методологическое решение касается опять-таки пулового проектирования и закупки вычислительно-коммуникационного оборудования и его попутной проверки на предмет наличия инородных аппаратурных и программных включений.
Пятое методологическое решение подразумевает всеобщее и обязательное переобучение административно-управленческого персонала (АУП) – например, в том же режиме дистанционного обучения и его регулярной жесткой сертифицирующей аттестации.
В результате предложенного санирования предстоит получить принципиально новый облик управленческой сферы российской экономики, способной обеспечивать поддержку управленческой деятельности в различных условиях и легко интегрироваться в мировую экономику.
1.10. Функциональная структура
системы поддержки управленческих решений
Решение управленческой задачи в общем случае предполагает (при условии наличия исходной информации, сформированной системой первичных сбора и обработки данных):
- формирование требований к информационной управленческой технологии;
- выбор информационной управленческой технологии из числа имеющихся или создание новой при отсутствии приемлемых;
- сбор исходных данных;
- применение информационной управленческой технологии.
Формирование требований к информационной управленческой технологии в принципе полностью аналогично в смысловом и процедурном плане случаю формирования требований к управляющей системе – сначала используется тот же перечень характеристик, а затем по ним вводятся пороговые значения, соответствующие неприемлемым уровням.
Выбор информационной управленческой технологии из числа имеющихся или создание новой при отсутствии приемлемых предусматривает:
- выявление множества потенциально применимых информационных управленческих технологий;
- идентификацию характеристик каждой из информационных управленческих технологий, вошедших в это множество;
- отсеивание тех информационных управленческих технологий, которые не удовлетворяют требованиям;
- в случае пустоты множества применимых информационных управленческих технологий переходят к созданию новой, а в случае неединичности этого множества осуществляется выбор предпочтительной по формализованному или неформализованному правилу.
Сбор исходных данных заключается в получении информации из внешних по отношении к системе управления источников и от самой себя относительно состояния объекта управления, управляющей системы и внешней по отношению к системе управления внешней среды, которая оказывает значимое воздействие на состояние объекта управления. Для этого задействуется система первичных сбора и обработки данных сообразно информационным потребностям системы выработки управленческих решений. Этот сбор может рассматриваться и более узко – как задачно-ориентированная выборка данных из базы данных, сформированных системой первичных сбора и обработки данных.
Применение информационной управленческой технологии состоит в реализации регламентированного ею процессора управляющей системы. Эта реализация предусматривает определенную последовательность инициализации подпроцессоров согласно их структурно-логическим информационным связям и технологической последовательности обработки информации или последовательности технологических операций обработки информации.
При создании и применении управляющей системы обязательным условием ее применимости является следование принципам кибернетического управления.
Эти принципы подразумевают:
- идентифицируемость (познаваемость и представимость в канонизированной форме) закономерностей функционирования объекта управления, т.е. идентифицируемость процессора объекта управления;
- реализуемость процессора управляющей системы;
- приемлемость характеристик управляющей системы в части информационной управленческой технологии.
Исходя из указанных принципов кибернетического управления, управляющая система и соответственно информационная управленческая технология должны нести всю полноту функциональной нагрузки по выработке управленческих решений, т.е. реализовывать некоторую группу функций управления как типовых технологических операций обработки информации. Эти функции представляют собой регламентированные процедуры реализации подпроцессоров управляющей системы (более точно – подпроцессоров системы выработки управленческих решений), часть из которые реализуется с помощью софтверного обеспечения, а часть – интеллекта АУП. Соответствующие подпроцессоры, как правило, именуются функциональными блоками. Функциональные блоки – это элементы структурного декомпозирования одновременно и управляющей системы и объективированной формы информационной управленческой технологии (так, например, некоторый специалист-управленец является и элементом управленческого потенциала как индивидуум и функциональным реализатором некоторого преобразования входной информации в выходную).
Таким образом, функциональный блок управляющей системы – это одновременно:
- подпроцессор системы выработки управленческих решений и субподпроцессор управляющей системы в целом как компонента, вычлененная при осуществлении процедуры структурного декомпозирования системы управления. В этом смысле он – объект, испытывающий в общем случае множественное информационное воздействие и, в свою очередь, оказывающий множественное информационное воздействие. Характер этих воздействий и соответствующих им связей носит определенный характер;
- сочетание части интеллекта АУП или компонент софтверного обеспечения, представляющее собой среду осуществления регламентированной типовой технологической операции обработки (преобразования) входной информации и создания выходной информации – реализации функции управления, предусмотренной информационной управленческой технологией.
С учетом выявленной множественности аспектов интерпретации функциональных блоков иногда функциональную структуризацию системы выработки управленческих решений и информационной управленческой технологии совмещают.
В организационно-экономических управляющих системах, исходя из уже выше применявшегося принципа обобщения для них понятий автоматизированных систем управления согласно действующей нормативной и методической документации принято выделять следующие функции управления:
- функцию учета, заключающуюся в обработке данных о состоянии объекта управления и внешней среды. Достаточно часто функция учета сводится к оценке ретроспективных значений показателей состояния, причем в нее условно включается и процессор системы первичных сбора и обработки исходных данных;
- функцию контроля, состоящую в сопоставлении заданного и реального состояния объекта управления по группе показателей состояния;