33. Контроль исполнения проекта и его перепроектирование

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

Контроль проекта может включать следующие процедуры:

32. Сбор отчетности о ходе работ по проекту

33. Анализ текущего состояния проекта относительно основных базовых показателей (результаты, стоимость, время)

34. Прогнозирование достижения целей проекта

35. Подготовку и анализ последствий корректирующих воздействий

Принятие решений о воздействиях и изменениях

Перепроектирование - концентрирует внимание и усилия на совершенствовании существующего процесса. Перепроектирование обычно применяют к тем процессам, которые успешно работают и в настоящий момент, но требуют коррекции в связи с изменившимися требованиями и потребностями клиента или потребителя. При перепроектировании процесса разрабатывается имитационная модель его текущего состояния. Перепроектирование имеет достаточно широкий спектр применения. По оценкам Д. Харрингтона, этот метод можно использовать для 70-90% основных бизнес-процессов. Нередко перепроектирование процесса проводят параллельно со сравнительным анализом (бенчмаркингом), чтобы перепроектированный процесс не оказался хуже или лучше соответствующего эталона.

Привлекательность перепроектирования процесса обусловлена тем, что этот метод позволяет уменьшать затраты, сокращать длительность цикла процесса, проводить работы от 80 до 100 дней и снижать количество ошибок на 30-60%.

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

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

34. Бизнес-планирование как форма технико-экономического обоснования проектов.

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

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

Бизнес-план — программный продукт, вырабатываемый в ходе бизнес-планирования.

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

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

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

Всесторонне изучив эту "проблему", я пришел к странному выводу, что ТЭО - это просто-напросто "урезанное" подобие бизнес-плана, а в некоторых случаях, это бизнес-план "обозванный" технико-экономическим обоснованием (ТЭО), и не более того.

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

Приведу некоторые из них:

36. Структурный план (резюме всех основных положений каждой главы);

37. Общие условия осуществления проекта и его исходные данные (авторы проекта, исходные данные по проекту, уже проведенные исследования стоимости и капиталовложений и т.д.);

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

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

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

41. Проектно-конструкторская документация (предварительное определение рамок проекта, технология производства и оборудование, объекты гражданского строительства, необходимые для нормального функционирования предприятия и т.д.);

42. Организация предприятия и накладные расходы (приблизительная организационная структура, сметные накладные расходы и т.д.);

43. Трудовые ресурсы (предполагаемые потребности в ресурсах с разбивкой по категориям рабочих: ИТР, служащие, основные специалисты (местные / иностранные); предполагаемые ежегодные расходы на трудовые ресурсы в соответствии с вышеуказанной классификацией, включая накладные расходы на оклады и заработную плату и т.д.);

44. Планирование сроков осуществления проекта (предполагаемый примерный график осуществления проекта, смета расходов на осуществление проекта, размеры траншей и т.д.);

Финансовая и экономическая оценка (общие инвестиционные издержки, финансирование проекта, производственные издержки, финансовая оценка, национальная экономическая оценка и т.д.).

Согласитесь, что структура технико-экономического обоснования (ТЭО), как две капли воды похожа на структуру добротного бизнес-плана.

Процесс проектирования базы данных состоит из трех основных этапов:

1. концептуальное;

2. логическое;

3. физическое проектирование.

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

Первый этап процесса проектирования базы данных называется концептуальным проектированием базы данных. Он заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации.

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

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

Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная модель).

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

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

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

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

Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической.

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

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

В случае реляционной модели данных под этим подразумевается следующее:

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

2. определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

3. разработка средств защиты создаваемой системы.

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

1. Они связаны с совершенно разными аспектами системы, поскольку отвечают на вопрос, что делать, а не как делать.

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

3. Они требуют совершенно разных навыков и опыта, поэтому требуют привлечения специалистов различного профиля.

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

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