Общая характеристика консалтинга

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

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

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

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

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

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

* опыт персонала, приобретаемый годами и десятилетиями при работе над конкретными проектами;

* независимость;

* объективность.

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

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

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

* формирование на основании анализа предложений по реорганизации организационно-управленческой структуры;

* упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

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

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

* рекомендации и предложения по применимости и внедрению существующих систем управления предприятиями (прежде всего классов MRP - manufacturing resource planning и ERP - enterprise resource planning).

Опишем этапы разработки консалтингового проекта более подробно.

1. Анализ первичных требований и планирование работ

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

2. Проведение обследования деятельности предприятия

В рамках данного этапа осуществляется:

* предварительное выявление требований, предъявляемых к будущей системе;

* определение оргштатной и топологической структур предприятия;

* определение перечня целевых задач (функций) предприятия;

* анализ распределения функций по подразделениям и сотрудникам;

* определение перечня применяемых на предприятии средств автоматизации.

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

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

* данные по оргштатной структуре предприятия;

* информация о принятых технологиях деятельности;

* стратегические цели и перспективы развития;

* результаты интервьюирования сотрудников (от руководителей до исполнителей нижнего звена);

* предложения сотрудников по усовершенствованию бизнес-процессов предприятия;

* нормативно-справочная документация;

* опыт системных аналитиков в части наличия типовых решений.

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

3. Построение моделей деятельности предприятия

На данном этапе осуществляется обработка результатов обследования и построение моделей деятельности предприятия следующих двух видов:

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

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

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

Переход от модели “как есть” к модели ”как должно быть” осуществляется следующими двумя способами.

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

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

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

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

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

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

4. Разработка системного проекта

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

На этом этапе определяются:

* архитектура системы, ее функции, внешние условия ее функционирования, распределение функций между аппаратной и программной частями;

* интерфейсы и распределение функций между человеком и системой;

* требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонент системы, их интерфейсы;

* состав людей и работ, имеющих отношение к системе;

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

Системный проект строится на основе модели “как должно быть” и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), информационную модель, например, в соответствии со стандартом IDEF1X, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).

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

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

* описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

* уменьшить затраты на разработку и внедрение системы;

* оценить разработку по времени и результатам;

* достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т.д.);

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

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

5. Разработка предложений по автоматизации предприятия

На основании системного проекта осуществляется:

* составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними;

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

* совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной системы;

* разработка требований к техническим средствам;

* разработка требований к программым средствам;

* разработка предложений по этапам и срокам автоматизации.

6. Разработка технического проекта

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

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

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

При этом происходит расширение системного проекта:

* за счет его уточнения;

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

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

7. Последующие этапы

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

Настройка существующей системы MRP или ERP осуществляется по следующим этапам

* наполнение системы фактическими данными;

* построение процедур их обработки;

* интеграция процедур внутри автоматизированных рабочих мест;

* интеграция автоматизированных рабочих мест в систему.

В.3. CASE-технологии - методологическая и инструментальная база консалтинга

За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer-Aided Software/System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Очень грубо, CASE - технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимоувязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и прогpаммистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.

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

Существует мнение, что CASE является наиболее перспективным направлением в программотехнике. С этим, естественно, можно и нужно спорить, но то, что CASE - наиболее бурно и интенсивно развиваемое направление, является в настоящее время фактом. Практически ни один серьезный зарубежный программный проект не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT (точнее ее подмножество IDEF0) принята в качестве стандарта на разработку ПО Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

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

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

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

* бизнес-анализ (фактически, модели деятельности предприятий “как есть” и ”как должно быть” строятся с применением методов структурного системного анализа и поддерживающих их CASE-средств);

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

Следует отметить, что CASE - не революция в программотехнике, а результат естественного эволюционного развития всей отрасли средств, называемых ранее инструментальными или технологическими. Однако это и не Confuse Array of Software that does Everything, существует ряд признаков и свойств, наличие которых позволяет классифицировать некоторый продукт как CASE-средство. Одним из ключевых признаков является поддержка методологий структурного системного анализа и проектирования.

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

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

* улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта);

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

* ускоряют процесс проектирования и разработки;

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

* поддерживают развитие и сопровождение разработки;

* поддерживают технологии повторного использования компонент разработки.

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

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

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

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

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

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

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

Составляющие технологии

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

Для консалтинговых компаний методикой является совокупность документов, описывающих:

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

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

* процедуры управления проектами;

* документацию, которая предоставляется клиентам в ходе работ.

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

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

Реинжиниринг бизнес-процессов.

Как научно-практическое направление, реинжиниринг бизнес-процессов впервые появился в США и за несколько лет превратился в одну из ведущих и активно развивающихся отраслей информатики. Сегодня начинается продвижение консалтинговых услуг и инструментариев по реинжинирингу и на российский рынок. Отечественная практика применения реинжиниринга показала, что этот метод необходим, особенно в условиях проведения глобальной экономической реформы и активного внедрения России в мировую экономическую систему. Впервые термин "реинжиниринг бизнес-процессов" (от англ. business process reengineering, BPR) был введен М.Хаммером, который определяет этот вид деятельности как "фундаментальное перепроектирование бизнес-процессов компаний для достижения коренных улучшений в основных актуальным показателях их деятельности: стоимость, качество, услуги и темпы".

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

Проблемы и их решение

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

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

Анализ информационных систем предприятия

Необходимым условием развития инфраструктуры ИТ предприятия является наличие точных и независимых данных о ее современном состоянии.

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

Разработка стратегии автоматизации

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

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

Выбор информационной системы

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

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

Оптимизация работы отдела ИТ

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

Управление внедрением

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

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

· 51 Управление информационных систем.

· 52 Организация финансового контроля на предприятии.

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

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

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

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

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

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

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

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

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

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

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

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

Научность - применение достижений науки и передового опыта в осуществлении контроля.

Гласность - своевременное информирование заинтересова