Проблемы внедрения корпоративных систем - Банк бесплатных рефератов, курсовых, дипломных работ

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

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

Внедрение должно быть действительно необходимо.

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

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

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

Любой софт требует сопровождения. Деловой особенно. Все изменения законодательства и учета на Вашем предприятии, - кто и как это будет делать? Если же изначально ясно, что внедрение предполагает проект с составлением ТЗ, кодированием и проч., то имейте в виду, что:

Самостоятельное внедрение так же эффективно, как и самолечение. Минздрав не рекомендует.

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

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

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

Москва словам не верит, - требуйте результат и Вы.

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

Ваша ответственность должна соответствовать Вашим полномочиям.

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

За работу системы Вам придется отвечать и через год, и через три.

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

Ваша позиция и авторитет будут зависеть от результатов внедрения.

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

Мы далеки от мысли, что этими десятью пунктами список проблем внедрения для IT-менеджера исчерпан. Тема по-прежнему остается волнующе открытой. Нас интересует Ваше мнение. Мы будем признательны, если Вы пришлете свое мнение с пометкой «Внедрение без обмана» по адресу: afed@intalev. ru

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

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

Постулат второй. Сложный маршрут, а простых внедрений не бывает, всегда состоит из этапов.

А теперь, внимание - парадоксально, но в общем случае любое внедрение имеет фиксированное количество обязательных этапов. Можете называть этот парадокс правилом «ИНТАЛЕВ». Что это за этапы?

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

Хотя «ответов» - это громко сказано. Как правило, цели впервые ясно и четко формулируются как раз в результате этого этапа.

Этап 2. Организационное проектирование. После понимания задач в бизнесе можно переходить к следующему этапу - постановке задач на автоматизацию. Кратко, понятно для топ-менеджеров должно быть описано - какие задачи будут автоматизированы и как. В ходе этапа составляется 5-15 схем движения информации (по одной на функциональную область - планирование продаж, закупка, хранение и т. д). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовке и IT-менеджер. В результате этого этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений фирмы. Таким образом, это, фактически, этап постановки задачи.

Важность этих двух этапов можно продемонстрировать следующим примером. Один из наших Заказчиков - крупное производственное предприятие, выбрало нас в качестве субподрядчика для разработки ТЗ и его кодирования. Все наши доводы насчёт необходимости планирования и постановки задачи были отметены. Руководство было непреклонно и не хотело (или не хотели?) «тратить время и деньги», - сразу же ТЗ! Мы предупредили о высокой вероятности неуспешности такого подхода. Увы, руководство сразу же спустило весь процесс написание ТЗ на начальников отделов, которые, естественно, не представляли системно всех задач. Мы их также не могли знать, поскольку это был не наш бизнес, не наше предприятие. После скоропостижного утверждения ТЗ и его кодировки выяснилось, что добрая половина автоматизированных бизнес-процессов была просто не нужна, поскольку руководство решило изменить их схемы выполнения, в другой половине были обнаружены грубые промахи (например, вследствие неверного понимания учётной политики). В результате тысячи долларов и несколько месяцев работ были потрачены для Заказчика впустую, о вероятности чего мы и предупреждали.

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

Этап 4. Техническое задание. Опираясь на утверждённую постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: «Что надо автоматизировать?», а ТЗ - «Как конкретно надо автоматизировать?». ТЗ составляется с IT-менеджерами и начальниками отделов - «собственниками бизнес-процессов». В нём детально описываются все объекты информационной системы, их поведение и т.д. И чем детальнее будет ТЗ, тем лучше. Не успокаивайтесь, если Вам скажут, что «не надо это описывать, это и так понятно». Документировать надо. В противном случае все кончается примерно так. В момент сдачи-приёмки Ваши предметные специалисты, с возмущением говорят, что не примут работы, поскольку-де: «нам ГОВОРИЛИ, что это будет сделано так, а сделано по-другому». Возникает коллизия, для разрешения которой одно средство - ТЗ. Все туда дружно смотрят. Скорее всего, как там написано, так и сделано. Формально прав внедренец (какое ужасное слово! Неужели, по-русски?). И теперь выбор в его руках - делать уступку и переделывать (платно либо бесплатно), или нет. НЕ ОТДАВАЙТЕ СВОЙ ВЫБОР В ЧУЖИЕ РУКИ.

Этап 5. Кодирование. После утверждения ТЗ можно приступать к кодированию. Это самый неинтересный этап. Внутреннее дело внедряющей организации.

Этап 6. Разработка должностных инструкций. На самом деле, этап 5 и этап 6 не обязательно последовательны. То есть, даже наоборот - лучше, чтобы они были параллельны. Их задача - подготовка этапа опытной эксплуатации - необходимо обучить пользователей работе с системой (а иногда и с ПК) и выдать им должностные инструкции. Без этого созданная система пропадёт, как бы хороша она не была Бывают Заказчики, пытающиеся сэкономить на этом этапе. Все та же псевдоэкономия времени и денег. Печально вздыхаем, - как правило, на этапе опытной эксплуатации они сами попросят сделать должностные инструкции. В итоге теряется время.

Этап 7. Обучение пользователей. Совершенно необходимо. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это значит, что Ваши сотрудники будут вынeждены работать по-новому. И проблема не только в том, что их нужно поставить в известность о грядущих изменениях и научить работе в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Раньше это называлось - «учесть человеческий фактор».

Этап 8. Опытная эксплуатация. Закодировано, начинается опытная эксплуатация. Очень важный этап. Этап, на котором можно объективно оценить все сделанное ранее. Система начинает работать не на бумаге. Требуйте ее чёткой и правильной работы.

С тем, как строить маршрут разобрались. Но помните? - важен маршрут и экипировка. Утверждаю - роль экипировки в многотрудном деле внедрения играет документированность результатов (кстати, этимология понятий «экипировка» и «оформление» представляется близкой, - правда, я не лингвист).

Итак, есть сложная, но результативная последовательность этапов. Каждый этап должен быть задокументирован и утверждён Заказчиком. Первый документ этапа - план его выполнения. Второй - план-факт исполнения работ. Третий - собственно результат этапа - «Отчёт о постановке задачи», «Схемы автоматизируемых бизнес-процессов», «Техническое задание», «Должностные инструкции».

У фирмы-внедренца (ой, опять новояз) должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? внедренец готов работать по любой предложенной Заказчиком форме? - плохой внедренец. Нельзя плясать под дудку Заказчика, ведь он не профессионал. Только представьте - (не дай Бог) приходите Вы к врачу - а он Вас спрашивает: «как будем лечиться?». То есть, нужен ещё один документ - в начале каждого этапа Заказчик должен утвердить формат документа результата по этому этапу. Хорошо, если они этот формат будет совпадать/коррелировать с общепринятыми - ГОСТы, IDEFы. Цель - предсказуемость результата.

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

Хороший академический вопрос - каково число измерений населяемого нами континуума. Интересно, что ответ, который давали на него физики и философы, сильно менялся в ходе того, что называется «прогрессом». (Что, кстати, заставляет с сомнением относится к окончательности последнего варианта).

Бизнесмены же не меняли свой взгляд никогда. И в Византии, и сейчас они знают твердо: у всего сущего есть ровно два значимых универсальных измерения- время и деньги. Говорим о них.

Итак, сроки. На сакраментальный вопрос: «Я хочу автоматизировать то-то и то-то, как быстро вы мне это сделаете?». Как правило, следует сакраментальный ответ: «Давайте, уточним, что именно Вам нужно. Ответ будет зависеть от этого. «Вопрос - правильный. Ответ - нет. На самом деле, - сроки внедрения в первую очередь определяются не сложностью задачи. Сроки внедрения определяются СКОРОСТЬЮ ПРИНЯТИЯ РЕШЕНИЯ ЗАКАЗЧИКОМ (при профессионализме внедренца, разумеется).

Пример. Допустим, есть некто. Некто хочет вылечиться от некоей болезни, лечение которой связано с операцией. (Аппендицит? - пусть). Время работы специалиста (врача) - 1-3 часа операции плюс минут двадцать в день на обход и около часа-двух на процедуры. Просуммируйте и сравните с общим временем нахождения больного в клинике (недели две, если все в порядке, а если и нет, то доля времени, которое тратят на больного врачи относительно времени его пребывания в стационаре почти не увеличивается - просто больной не выписывается, а процедуры не прекращаются). То есть, для конкретно взятой болезни, при конкретном медколлективе, время выздоровления может меняться в РАЗЫ в зависимости от пациента! Короче, вывод следующий - время выздоровления определяется в первую очередь состоянием организма, который лечат, а не тем временем, которое уделили больному организму врачи.

Теперь про автоматизацию. Постановка задачи на автоматизацию зависит (сильно) от той среды, в которой будет происходить автоматизация. Информационные потоки нельзя проектировать в отрыве от среды их воплощения. Еще конкретнее - постановка задачи процентов на ... (много!) определяется тем средством, которое будет выбрано для решения. Ставить задачу будет руководство Вашего предприятия и предметные специалисты. Как хорошо они представляют средства, с помощью которых задача будет решаться? Вопрос риторический. На самом деле, постановка задачи на автоматизацию системы управления (предприятием, функциональной областью деятельности или конкретным бизнес-процессом) - это процесс, в котором принимают РАВНОПРАВНОЕ участие две стороны - внедряющая фирма, которая (как предполагается) хорошо владеет средствами автоматизации, и специалисты Вашей фирмы. В процессе внедрения последним придется узнать гораздо больше нового, чем специалистам внедряющей фирмы (говорим о настоящем!). Вывод тривиален - время, которое придется затратить специалистам и руководству Вашего предприятия на выбор оптимальной схемы информационных потоков и бизнес-процессов (ведь решение принимать им, а не внедренцу), существенно больше того времени, в течение которого специалистам внедряющей фирмы (повторюсь, если они настоящие), придется разбираться в нюансах бизнес-процессов Вашего предприятия для подготовки вариантов этих схем.

Пример. Время, в течение которого мы ставили и автоматизировали комплексную систему управления предприятием (автоматизация систем планирования, учета, контроля и анализа) одному из наших Заказчиков, составило три месяца. Время, в течение которого мы ставили и автоматизировали подсистему расчета зарплаты другому нашему Заказчику (оба сравнимы по количеству персонала) составило полгода. Подчеркну, время автоматизации аналогичной подсистемы в первом случае заняло бы 2 недели. И в том, и в другом случае работали одни и те же наши специалисты. В чем разница? В скорости принятия решения Заказчиком. В первом случае речь шла о коммерческом предприятии с жестким механизмом управления и слаженной, заинтересованной в результате командой, во втором - о постсоциалистическом предприятии с богатой наследственностью.

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

Если же вернуться к вопросу, с которого начали - «сколько времени займет внедрение?», то после 2-4 встреч с руководством фирмы-Заказчика, каждая продолжительностью около часа, время внедрения можно будет оценить с погрешностью в процентов 40. На этом этапе уже станет ясна и примерная сложность задачи и то, как и сколько времени Заказчик реагирует на предложения и вопросы, сколько у него отвественных и существует ли ясный механизм принятия решения и т.д.. Продолжая медицинские аналогии, серия этих встреч - не что иное как бесплатное предгоспитализационное обследование (общий диагноз, выявление всяких аллергий, противопоказаний и проч.).

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

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

Способ 2. Проектный. Способ, любимый руководством автоматизируемых предприятий за кажущуюся простоту и ясность. Нет, способ действительно ясный, но вот последствий этой ясности Заказчик себе, как правило, не представляет. И это может привести к серьезным проблемам.

Коротко суть проектного способа определения стоимости внедрения. Стороны четко оговаривают что, в какие сроки и за какие деньги будет сделано. Серьезная внедряющая фирма формализует это в договорных документах следующим способом: Постановка задачи определяет, что именно должно быть сделано; ТЗ определяет, как должно быть сделано то и только то, что определено в Постановке; Кодирование - кодируется то и только то, что определено в ТЗ. Такая система позволяет внедряющей фирме точно определить себестоимость и стоимость проекта, а также планировать ресурсы. НО! Что произойдет, если после подписания договора и Постановки задачи, Заказчик вдруг обнаружит, что по какой-либо причине, стоящие задачи изменились таким образом, что часть заявленных в Постановке задач в том виде, в каком они акцептованы внедренцем, ему УЖЕ НЕ НУЖНА?! Внедряющая фирма на основании подписанных простых и ясных документов имеет полное право (по крайней мере, доказать это в любой инстанции не составит труда) сделать ненужную работу и добиться оплаты ее договорной цены. Кроме того, коль скоро сроки работ определены, то внедряющей фирме не выгодно их растягивать - норма прибыли уменьшается, и она обязательно будет использовать подписанные документы с оговоренными сроками для того, чтобы не дать Заказчику затянуть сроки (увеличить скорость принятия решения Заказчиком).

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

Способ 3. Рамочный договор о сотрудничестве. Жизненность этого способа определяется его гибкостью. Если после предварительных 2-4 встреч с руководством (помните - в начале статьи?) задачи, сроки и, следовательно, стоимость внедрения можно оценить с погрешностью до 40%, то после этапа постановки задачи ситуация определяется с погрешностью до 10%. В зависимости от того, на каком этапе при проектном способе работы принимается решение о проекте, Заказчик рискует «попасть» либо в эти 40, либо в те 10 процентов риска. В отличие от проектного способа стороны констатируют общее видение предполагаемых задач, сроков и стоимости, но фиксируют лишь те задачи и этапы работ, которые им ясны на 100% (принимая на себя двустороннюю ответственность), и договориваются о том, что новые задачи будут формулироваться и выполняться оговоренным способом по мере их прояснения. И так до тех пор, пока окончательная цель не будет достигнута. Меньшая жесткость - меньший риск. Возможность внесения оперативных корректировок гарантирует меньший расход ресурсов (они не тратятся на выполнение ненужной работы), а значит гарантирует лучшее, по сравнению с проектным способом, соотношение результат/цена.

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

А все просто. Итак, процесс управления практически любым объектом можно представить следующим циклом:

Если, скажем, мы управляем кораблем, то Целеполагание - это принятие решения доплыть, например, из Ливерпульской гавани в Бразилию; Планирование - это решение о том, что для пополнения запаса горючего нам необходимо зайти в промежуточный порт, пусть, на Кубу; Исполнение - это, собственно, плавание; Контроль - это необходимость прочитать название порта и убедиться, что попали именно на Кубу, а не в Кабул; Анализ - соотнесение желаемого местонахождения с действительным; Формирование управленческого воздействия - оргвыводы и приказ заменить проштрафившегося штурмана; Корректировка - изменение планов или целей в зависимости от величины промаха; ну и так далее.

Оставим пока в стороне вопрос о том, что именно является объектом управления в контексте внедрения. Важно, что автоматизированная система управления в общем случае должна автоматизировать именно этот цикл, так как именно он является определением термина «управление». Вопрос в том, какие фазы управленческого цикла подлежат автоматизации? Достаточно очевидно, что не целеполагание и корректировка, которые пока являются прерогативой человека, поскольку на этих этапах разрабатывается/корректируется миссия, стратегия предприятия, его глобальные планы (имеющие, в основном, качественную оценку), или производится изменение плана - процесс тоже не подлежащий алгоритмизации. Помочь в этом человеку может только другой (чуть не сказал «человек») консультант. Хорошо, если фирма-внедренец имеет отдел консалтинга и при необходимости будет готова выделить опытных консультантов по этим вопросам. Формирование управленческого воздействия - процесс волевой в не меньшей степени, чем интеллектуальный. Компьютер тоже ничем не поможет. На всех же остальных стадиях автоматизация весьма и весьма уместна. В любом случае, сбои на любой стадии управления приводят к тому, что объект становится плохо или вовсе неуправляемым.

Итак, вывод - при автоматизации системы управления предприятием автоматизировать нужно фазы планирования, исполнения, контроля и анализа. Все четыре. А если к вам приходит фирма-автоматизатор и утверждает, что после проведенной ею автоматизации, скажем, бухучета, наступит полный порядок, так сказать, - то это вряд ли. Бухучет принадлежит фазе контроля. Допустим, знаете вы месячный объем продаж. Ну и что? Его не с чем сравнивать, следовательно, непонятно как регулировать этот объём. А если бы у предприятия существовал план по объёму продаж, то каждый день менеджер получал бы информацию: укладывается он в план или нет, и в результате чего возникло отклонение. Согласны, что в этом случае менеджер действительно владеет информацией и является именно менеджером, а не бухгалтером или секретарём?

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

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

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

В качестве платформы для автоматизации выберем систему «1C: Предприятие 7. 7»», которая, как показывает практика, является самой распространенной среди внедренцев. Для реализации подобной схемы бюджетирования в системе разрабатываются соответствующие бюджетам документы. Важно, что внесение информации в систему по части бюджетов удобно выполнять не через документы (в терминах 1С), а через электронные таблицы, которые разрабатываются в системе «1С: Предприятие 7. 7». Естественно, часть данных является расчётными показателями. Для этого в системе разрабатываются соответствующие справочники. Например, на приведённой схеме планирования бюджет закупок получается автоматически из бюджетов продаж, производства, справочников рецептуры (калькуляции), норм закупок разного сырья у поставщиков, сроков доставки и переработки сырья.

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

Финансовый директор делает в системе пометку о начале планирования.

Автоматически всем указанным ранее пользователям рассылается сообщение (да-да, как в MS Outlook) о начале планирования следующего периода, его сроках и deadline предоставления плана. Все это в 1С можно реализовать.

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

Он указывает номер декады (недели, точную дату - всё зависит от выбранной модели), статью расхода и сумму. При этом заранее составлена проекция менеджеров, участвующих в планировании, на статьи затрат. Это значит, что IT-менеджер никак не сможет планировать налоги или зарплату основного производственного персонала, поскольку ему это запрещено. Но выбрать статью - оргтехника и провести по ней 600 USD (поддержание и текущий ремонт) он сможет.

Завершив планирование, менеджер оценивает свои планы, что-то меняет и ставит отметку.

Автоматически система формирует сообщение, что тогда-то такой-то IT-менеджер предоставил все планы.

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

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

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

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

В результате сформирован чёткий план расходов и выплат предприятия на предстоящий период. На практике процедура разработки и утверждения подобных планов занимает от 3 до 10 дней в зависимости от сложности бизнеса и скорости принятия РЕШЕНИЙ, о которой речь шла в предыдущей статье. Учитывая требования конкретного менеджмента, указанная процедура может быть проще или сложнее. Например, возможно лимитирование определённых статей (в абсолютных величинах или в процентах от других статей) - на рекламу нельзя тратить более 6% от всех поступлений от продаж и т.д. Пожалуйста, система усложняется, но продолжает оставаться реализуемой в системе «1С: Предприятие 7. 7. «

Для большинства предприятий, как показывает практика, вместе с автоматизацией планирования необходима его первоначальная постановка, т. е. разработка схемы и регламента бюджетирования. Хорошо, когда клиент прямо заявляет о своей проблеме в этой области и готов на помощь со стороны консалтинга: ранняя диагностика - меньше осложнений. А процентов 80, как показывает практика, - нет (то ли не знают, то ли стесняются). Тогда выход один, если внедренец - фирма толковая, гордая, и болеющая за своих клиентов, то в процессе разработки постановки задачи и ТЗ, аккуратно, в необходимом объёме (возможно, без разработки красивых, но часто бестолковых положений) она проведет разработку схем и регламента планирования. Так сказать, окажет «скрытый консалтинг». Но учтите предыдущее лирическое отступление - для этого нужны очень опытные и образованные постановщики.

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

Какое отношение социализм имеет к проблемам внедрения? Никакого. Просто, вспомнил сакраментальное: «Социализм - это, прежде всего, учет и контроль». А в предыдущей статье мы говорили о некоем цикле управления, в котором, правда, не было фазы «Учет», но и фаз было не две, а больше. А еще говорилось, что если фаз управления меньше, чем должно быть, то объект неуправляем, а значит, врежется наверняка! Вспомнили?

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

Подчинённый IT-менеджера (или он сам) должен был ввести в систему заявку на выплату, допустим, 630 USD (а запланировано было, как вы помните, 600), указать статью - поддержание оргтехники, и способ оплаты - безналичный (тоже бывает).

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

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

Финансовый директор получал сообщение о новой заявке от IT-менеджера, видел перерасход по ней и текущий остаток денежных средств на том счёте, с которого она будет уплачена.

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

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

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

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

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

Что такое Учет, или Стоит ли говорить о второстепенном?

Мы говорим выполнение, подразумеваем... Что и говорить, термин «учет» пользуется чрезвычайной популярностью. На мой взгляд, он имеет пусть важное, но достаточно подчиненное значение в системе управления предприятием. К сожалению, то исключительное внимание, которое ему уделяют большинство внедренцев, чревато - на практике это означает недооценку других аспектов внедрения КИС. Предупреждаю, глава будет очень скучной и говориться будут вещи ТРИВИАЛЬНЫЕ. Ниже я покажу, что они действительно второстепенны, а пока, что делать, - придется потерпеть. Итак, учет бывает бухгалтерским и управленческим.

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

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

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

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

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

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

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

Необходимость одновременного ведения разных систем бухучета для одного предприятия (например, хозяйственного, бюджетного, в системе GAAP);

Необходимость ведения нескольких «бухгалтерий» одного предприятия (мы имели ввиду холдинг, а вы что подумали?);

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

Необходимость стыковки с разнообразным периферийным оборудованием (кассовые аппараты, штрих-кодовое оборудование, АТС и т.д.)

Построение территориально-распределенной системы автоматизации;

Использование различных программных платформ...

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

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

А теперь о Главном. Если вы обратили внимание, в основе схемы фазы выполнения лежит тот же цикл управления, о котором мы говорили в предыдущей статье. Не надо сильно напрягаться для того, чтобы увидеть старых знакомых - Целеполагание, Планирование, Выполнение, Контроль, Корректировка, Формирование управленческого воздействия. Вы их видите? Парадокс? Да, нет же! Любая подсистема управляемой системы должна и может быть УПРАВЛЯЕМА! И коль скоро это так, цикл управления и методы его автоматизации принципиально одинаковы, идет ли речь о предприятии в целом, некоторой области его деятельности (маркетинг, закупка/продажа, производство, управление персоналом и т.д.) или конкретных бизнес-процессах, являющихся частью областей деятельности.

Если перенестись в мир геометрических аллегорий, то цикл управления является типичным фракталом - регулярным геометрическим элементом, часть или части которого могут в свою очередь являться исходным элементом, представляя собой зримый образ рекурсии. Узоров, являющихся комбинациями циклов-колец бесконечно много, и каждый конкретный узор может являться интерпретацией/описанием системы управления неким РЕАЛЬНЫМ объектом/предприятием. Или наоборот, любое управляемое предприятие является просто интерпретацией какого-то переплетения колец. Совершенный узор - совершенная система управления - совершенное предприятие. Любой изъян в узоре означает СОВЕРШЕННО РЕАЛЬНЫЕ ПРОБЛЕМЫ в этой жизни.

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

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

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

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

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

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

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

Определение и согласование параметров заказываемого товара с продающими филиалами

Контроль качества и определение условий хранения

В результате анализа деятельности педприятия за предыдущий период выяснилось следующее: периодически возникала ситуация, когда закупаемый товар по своим характеристикам (номенклатура, размер и проч.) существенно отличался от заказываемого филиалами. Это приводило к серьезным проблемам и потерям в сбыте. Было решено ввести еще один этап (между этапами 2 и 3). Этим новым звеном стал этап Согласования. Появились две новые должности: 1) менеджер, отвечающий за согласование отклонений с поставщиком. Он несет ответственность за то, что поступит именно согласованный товар; 2) менеджер, отвечающий за то, что согласованный товар будет востребован и продан филиалом. И, представьте, одного этого оказалось достаточно для существенного сокращения потерь!

В предыдущих статьях мы говорили о системе управления, экономике и технологии внедрения. О человеческом факторе, и о том, кажется, говорили. Не говорили лишь о том, что такое автоматизация. Не говорили потому, что на практике большинство внедрений КИС и так сводится почти исключительно к автоматизации как таковой (мол, КИС - это просто hard&soft, а прочее - от Лукавого). А я считал и считаю основной задачей цикла статей - привлечение внимания к неочевидным для большинства аспектам внедрения. И именно поэтому сейчас предметом обсуждения будет такая очевидная и такая НЕОЧЕВИДНАЯ автоматизация.

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

Коэффициент автоматизации (AQ) ~ 1/Кол-во алгоритмизируемых ручных операций

Т. е. чем больше осталось ручной рутинной (напомню, routine - по английски программа) работы, тем он ниже.

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

Пример 1. Опасность недоавтоматизации. На некотором предприятии в системе была реализована поддержка планов планирования, учета и контроля. Вроде бы хорошо. В числе прочих составлялся бюджет выплат. Но на самом деле учет выполнения планов велся без предварительного контроля, т. е. при плане выплат в 100 единиц сотрудник мог сделать платеж на 500 и на следующий день менеджер видел результаты контроля - отклонение -400. Правда, было уже поздно, так как отменить действие было невозможно. Поэтому перед любым платежом сотруднику приходилось сопоставлять план выплат, уже произведенные выплаты и намеченную, а хранилось они в разных подсистемах и т.д. и т. п... = время, раздражение, ошибки. А достаточно было просто проработать механизм лимитирования и при попытке превышения лимита оператор получал бы соответствующее уведомление и рекомендацию отправить заявку на согласование и утверждение. Т. е. система с необходимой степенью гибкости реагировала бы, и больше того, даже регламентировала бы деятельность оператора. Т. е. коэффициент автоматизации - это IQ КИС.

Пример 2. Опасность переавтоматизации. Предприятие купило престижную КИС (западного производства), вложив в нее сотни тысяч долларов. Номенклатура товаров - около 10 000, поставок - до 500 в день. Так вот, вместо обычных кладовщиков предприятие вынуждено было взять на работу квалифицированных программистов (хорошо, склад в Санкт-Петербурге, а не где-нибудь в провинции) для ввода накладных и подготовки отчетности. А все потому, что в этой КИС товар представлялся двенадцатизначным кодом, и пользователю каждый раз требовалось набирать в документах эти цифры, специальным образом ежедневно расшифровывать из данных штрих-кодового оборудования, копировать и импортировать файлы, и снова преобразовывать коды в отчетах. А любая ошибка или несвоевременное выполнение операций, приводили к серьезным проблемам. То есть оперативность и достоверность информации, которую предоставляла КИС, зависела от такого числа человеческих факторов, что сбои были фактически запланированы.

Один интересный вывод, подчеркивающий близость IQ и AQ. Знаменитый закон Тейлора гласит - «из двух кандидатов, одинаково пригодных для работы, следует выбрать более глупого». То же и с КИС - из двух КИС, одинаково пригодных для автоматизации вашего предприятия, следует выбрать ту, у которой AQ ниже (более глупую). По крайней мере денег сэкономите.

А теперь итог. Приведу определение КИС - это автоматизированная система сбора, хранения, обработки и предоставления информации для целей управления предприятием. Выделим главное:

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

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

Что такое автоматизация, мы говорили в начале статьи. Системы управления можно классифицировать по значению коэффициента автоматизации AQ.

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

К сожалению, большинство предприятий в пространстве КИС находятся вблизи «абсолютного нуля», и абсолютно все предприятия хотят находиться по диагонали от него, и как можно дальше. Проблема заключается в том, что сделать это в один присест, да еще само собой не удастся. В современной русской управленческой психологии, ярчайшим представителем которой является Владимир Тарасов, есть такой принцип - «путь из беспорядка в «полный порядок» лежит через упрощенный порядок». Следствием этого является то, что невозможно из «абсолютного нуля» (беспорядка) сразу перейти куда-то далеко по диагонали (полный порядок). Следовательно любая попытка мгновенного и легкого достижения полного порядка ненаучна или, по-простому, обречена. Но после каждого частичного улучшения, устраняющего частицу беспорядка, необходимо ставить конкретную ДОСТИЖИМУЮ цель, приближающую к порядку. «Навигирование» в этом пространстве имеет свою специфику и безопасно (без неприятных последствий разного рода) в нем перемещаться можно, только используя специальную методику.

Описание предмета: «Маркетинг»

МАРКЕТИНГ (англ. marketing) — 1) комплексная научная система организации и управления производственной, коммерческой и сбытовой деятельностью предприятия, ориентированной на выявление неизвестных и неудовлетворенных запросов потребителей; 2) один из важнейших способов активизации конкурентных начал рыночной экономики; 3) качественно новая философия производства и сбыта продукции и услуг в условиях развитой рыночной экономики.

Маркетинг возник в 20-е годы XX в. в США, широкое распространение (в практике ведущих компаний) получил в 50—60-х годах в связи с обострением проблем сбыта и усиливающейся монополизации рынка[3]. Главные цели маркетинга - извлечение максимальной прибыли; исследование и прогнозирование емкости рынка, индекса цен, товарной конъюнктуры, определение потенциальных потребителей и производителей; изучение внутренней и внешней среды его развития, разработка, производство и сбыт товаров и услуг, пользующихся спросом; формирование спроса у потребителей на новые товары, услуги и изделия. Основными функциями маркетинга являются: выявление существующего и потенциального спроса покупателя на товары и услуги посредством комплексного исследования состояния рынка и перспектив его развития; организация научно-исследовательской деятельности по созданию новых образцов продукции, а также улучшению прежних моделей в соответствии с запросами потребителей; координация и планирование производства соответствующих товаров, инвестиционной и финансовой политики; определение наиболее эффективных форм и методов сбыта продукции; регулирование всей экономической деятельности, включая руководство производством, транспортировкой, упаковкой, сбытом, рекламой, техническим обслуживанием и другими услугами и мероприятиями по расширению сбыта и контроль за реализацией намеченных программ; формирование и реализация ценовой политики, информационное обеспечение маркетинга. В процессе своего развития маркетинг проходит ряд этапов. На первом этапе осуществляются рыночные исследования: определяется потенциальный спрос отдельных групп населения, предприятий, организаций и других потребителей, которым предназначается создаваемая новая продукция.

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

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

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

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

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

Внимание!

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

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