О. А. Йылмаз архитектура предприятия
Скачать 1.65 Mb.
|
Стратег, который взаимодействует с руководством организации и форму-лирует на понятном специалистам по информационным технологиям язы-ке те бизнес-требования, которые должны найти отражение в Архитектуре предприятия. Проектировщик, ответственный за определение общих архитектурных принципов. Тренер, который специализируется на объяснении высшему руководству и бизнес-пользователям необходимости и преимуществ Архитектуры пред-приятия. Советники, которые обеспечивают взаимодействие с командами, реализу-ющими отдельные программы и проекты, а также отслеживают перспектив-ные технологии и изменения в окружении. Контролер, отвечающий за постоянное сравнение всех проходящих клю-чевых преобразований с планом, а также эа необходимые изменения в плане в соответствии с потребностями организации. Помимо собственно команды проекта, в организации должны существо-вать некоторые формальные структуры, каждая из которых выполняет опреде-ленные руководящие и контролирующие функции. Обычно создаются такие структуры, как Управляющий или Информационный комитет, утверждающий об-щий ИТ-бюджет и ИТ-стратегию коипании, и Совет по архитектуре (или Техниче-ский комитет), который следит за организацией процесса разработки архитек-туры, а также рассматривает и санкционирует отклонения от утвержденной ар-хитектуры. Важно подчеркнуть, что, хотя команда проекта разработки архитектуры и выполняет основную работу, она, как правило, не является собственником этого процесса и результатов. Целесообразно, чтобы ее результаты были сформирова-ны в виде рекомендаций, подлежащих утверждению высшим руководством ор-ганизации для придания определенной значимости и легитимности. Более того, команда проекта или служба Главного Архитектора не должна сама выполнять «полицейские» функции в случае несоответствия проектов утвержденным архи-тектурным стандартам. Если вы решили, что Архитектура предприятия должна затрагивать еще партнеров и поставщиков, то, следовательно, это потребует определенного уча-стия их представителей в работе. Или наоборот, вы сознательно выберете некую часть предприятия, наиболее важную, и только часть бизнес--процессов организации. Предположим, что команда проекта разработки архитектуры сформирова-на и готова начать свою работу. Как и для традиционных проектов, прежде все-го следует обеспечить формализацию этого процесса путем составления и ут-верждения устава проекта. Такой устав определяет задачи проекта, график вы-полнения, используемый подход и процедуры, а также фиксирует тот факт, что эта деятельность поддержана руководством организации. Соответственно, та-кой устав должен будет периодически, обычно раз в год пересматриваться и ут-верждаться Управляющим комитетом организации. При переходе к практической реализации очевидно, что для достижения конечной цели необходимо предварительно определить некоторую согласован-ную основу. В качестве такой основы может выступить набор архитектурных мо-делей высокого уровня. Сформированный таким образом набор моделей документируется в произ-вольном формате, например, в виде обычного файла текстового редактора. По-скольку его основным назначением является использование для широкого об-суждения не только внутри команды проекта, но и с представителями различных подразделений,то применение специализированных средств моделирования на данном этапе может затруднить взаииодействие из-за отсутствия у всех участ-ников необходимой подготовки и установленных специализированных средств. Например, даже применение UML-диаграмм может быть избыточно сложным для обсуждения со специалистами бизнес-подразделений. Еще раз стоит подчеркнуть, что на данном этапе не следует углубляться в излишнюю детализацию. Напротив, более важным является «расширение» об-ласти охвата. При этом временные рамки этапа также должны быть четко опре-делены и ограничены - так что даже для больших компаний срок реализации этапа с учетом обсуждений и согласований не должен превышать трех месяцев, а для мелких и средних - значительно меньше. Другой важной задачей начального этапа будет выбор и согласование вну-три команды наиболее подходящей методики или модели (framework) для де-тального описания архитектуры. В главе 2 рассмотрены несколько распространенных методик и даже указаны некоторые сравнительные характе-ристики. Какой-либо одной, обязательной к применению методики не существу-ет - каждая организация вправе выбирать ту, которая наиболее для нее удобна. Самым целесообразным будет выбор одной из методик в качестве основной с дополнением элементов других методик. Необходимым шагом будет документи-рование выбранного решения (или точнее, выбранного подмножества) с тем, чтобы это краткое, не более чем на 10 страниц, описание могло быть использо-вано командой проекта в качестве методологической основы. Другими важными документами, которые будут использоваться в качестве основы, являются:
В целом, как отмечается в публикации, для успеха архитектурного проекта необходимы следующие пять элементов:
Реальный эффект достигается за счет синергетического сочетания всех этих элементов, так что отсутствие или недостаточность отдельных частей может приводить к следующим вариантам неудач:
Создание организационных структур и выстраивание процесса управления разработкой, практическим использованием и обеспечением соответствия при-нятой архитектуре является одним из ключевых факторов успеха. Для этого процесс в английском языке используется термин «governance». Таким образом, эта функция управления и контроля включает два аспекта:
Реализация управления и контроля естественно предполагает участие представителей бизнес-подразделений в работе над архитектурой. То есть уп-равление и контроль архитектурного процесса включает такие аспекты, как пер-сонал, правила (политики) и процессы, которые должны обеспечивать средства обеспечения свободы действий и принятия решений без нарушения общих пра-вил, установленных архитектурой. Это предполагает принятие правил и выра-ботку руководств, которые бы задавали стандарты поведения по отношению к архитектуре предприятия. А за этим следует определение способов выполнения правил, т.е. процессов, обеспечивающих исполнение этих правил и руководств (включая методы контроля, список контролируемых параметров, информирова-ние и применение санкций, связанных с несоблюдением правил). Вообще говоря, следует отличать понятие управления и контроля архитек-турного процесса от более широкого понятия управления и контроля использо-вания ИТ на предприятии в целом. Ранее уже отмечалось то, что разработка архитектуры строится на основе двух групп механизмов. Первая группа механизмов - это архитектурные прин-ципы: условно говоря, «неявные» (implicit - по аналогии с принципами управ-ления знаниями) механизмы. Вторая группа механизмов описания архитектуры включает определение формальных стандартов, моделей и требований, - «яв-ные» (explicit) инструменты и механизмы. Важный аспект заключается в том, что инструменты управления и контро-ля архитектурного процесса должны включать различные способы, которые предполагают обеспечение соответствия как «неявным» элементам архитектуры (принципам), так и «явным» (стандартам). Обеспечение следования принципам достигается прежде всего через «мягкие» механизмы: информирование и ком-муникации, обеспечение общего понимания и добровольного принятия. Обеспе-чение выполнения стандартов и правил как части архитектуры требует более «жестких» формальных механизмов, таких как формальные процедуры рассмо-трения и проверок, процедуры рассмотрения исключений из правил, штрафные санкции. В тех же случаях, когда по определенным, явно сформулированным и обос-нованным бизнес-причинам какая-либо система или прикладное решение не может соответствовать принятой архитектуре, в рамках функции надзора не-обходимо обеспечить, чтобы функциональные и бизнес-подразделения понима-ли реальную стоимость реализации и использования таких несоответствующих архитектуре систем и решений. Эта дополнительная стоимость может быть свя-зана с более высокими затратами на эксплуатацию или отсутствием гибкости в дальнейшем развитии решений. Точно так же, как и во многих других областях, формирование структур и процессов управления и контроля Архитектуры предприятия лучше всего начать с формулировки руководящих принципов. Приведем только некоторые из них, которые представляются достаточно важными и универсальными:
Вообще говоря, наиболее общими подходами обеспечения управления и контроля архитектуры являются следующие: Публикации и распространение информации и документов описания архитектуры. На самом деле, публикация архи-тектурных документов является очень важным аспектом всего процесса управления архитектурой, но сам по себе этот инструмент не будет рабо-тать без других механизмов. С разработкой и реализацией архитектуры предприятия связаны интересы большого количества сторон, поэтому ин формация об архитектуре должна распространяться внутри организации на различных уровнях, в том числе с использованием визуальных, графи-ческих средств представления или специализированных языков. Для выс-шего руководства архитектура должна демонстрировать, как она обеспечи-вает достижение бизнес-целей и какие преимущества будут получены. Об-ластью интереса бизнес-пользователей являются их специфические пред-метные области и функциональные потребности. Руководители в области ИТ и технический персонал больше сфокусированы на технических компо-нентах, включая то, как впоследствии будет обеспечиваться поддержка и сопровождение разрабатываемых решений. Архитекторов отдельных про-ектов волнуют такие вопросы, как стандарты, шаблоны и правила, пригод-ные для повторного использования либо накладывающие ограничения на дизайн отдельных решений. Публикуя информацию об архитектуре, нужно стреииться удовлетворить все перечисленные категории заинтересован-ных сторон. Более того, чем более открытой является эта информация вну-три предприятия (эа исключением, возможно, определенных аспектов ар-хитектуры безопасности), тем больший эффект это принесет. Создание формальных структур, таких как Совет по архитектуре. На регулярных заседаниях таких формальных структур должны рассматри-ваться, в частности, архитектурные вопросы новых систем и инициатив. Эти структуры должны утверждать или отвергать проекты, в зависимости отто-го, насколько соблюдены принятые в архитектуре принципы, модели и стандарты. Большим преимуществом является ситуация, когда методики разработки систем и процессов управления проектами широко известны и используются в организации и когда рассмотрение проекта Советом по ар-хитектуре является стандартным этапом процесса. Конечно, возможность этого комитета говорить «да» или «нет» по поводу проектов является важ-ной, но даже сам факт наличия формального процесса рассмотрения про-ектов на соответствие архитектуре имеет колоссальный положительный эффект. Недостатками этого метода управления могут оказаться: дополни-тельный уровень бюрократии, отсутствие у комитета реальных рычагов из-менения проектировочных решений, вазможность задержек в рассмотре-нии вопросов в ситуации, когда требуется быстрое принятие решений. Контроль процесса закупок. Предполагается такое выстраивание процес-са, когда закупка продуктов и технологий, соответствующих архитектуре, выполняется легко и просто, а покупка нестандартных с точки зрения при-нятой архитектуры продуктов существенно затруднена. Обеспечение связи между процессом закупок информационных технологий и стандартов ар-хитектуры является ключевым способам институализации архитектуры и ее «внедрения» в культуру деятельности предприятия. Обеспечение консультирования по вопросам архитектуры. Это наибо-лее эффективный, имеющий минимальный уровень бюрократии процесс управления архитектурой. Он состоит в использовании ресурсов внутрен-них консультантов па вопросам архитектуры на самых ранних этапах про-ектов; они дают рекомендации, касающиеся выбора технологий и общих принципов проектирования системы. В отличие от формальных методов контроля, рассмотрения на комитетах и модель, предполагающая кон-сультирование, является проактивной и упреждающей. Конечно, и у этого способа есть свои ограничения, поскольку есть опасность, что ограничен-ные ресурсы группы, отвечающей за разработку архитектуры, станут чрез-мерно распыляться на работу по отдельным проектам. На самом деле, наиболее эффективным способом является сочетание всех перечисленных выше подходов на различных этапах реализации ИТ-проектов и систем так, как показано на рис. 1.10 Например, создание документов с описа-нием элементов архитектуры, таких как шаблоны проектирования, позволяет пе-редать сообществу ИТ-специалистов информацию о коллективном передовом опыте, что важно в самом начале любого проекта. Это задает общую основу для архитектуры конкретного решения и используемых технологий. На этапе выработки требований к системе консультирование со стороны архитектурной группы может помочь в выборе конкретных проектировочных ре-шений и технологий. Это поможет избежать возможных конфликтов в будущем, поскольку с самого начала будет задано направление в использовании стан-дартных для организации подходов. При этом период такого консультирования должен быть краткосрочным, чтобы не перегружать ресурсы группы, отвечаю-щей за архитектуру предприятия в целом. В конце этапа проектирования система рассматривается тем или иным кон-тролирующим органом. Это одновременно является и контрольным механизмом, и механизмом информирования более широкой аудитории о проекте и исполь-зуемых проектировочных решениях.  Рис. 1.10. Управление и контроль на разных этапах разработки архитектуры предприятия После того, как архитектура конкретного решения утверждена, может на-ступить этап закупки аппаратного и программного обеспечения. Связь архитек-турного процесса с процессами закупок является гарантом использования стан-дартных для организации решений и технологий. Интересными являются данные о том, какие механизмы - жестко контро-лируемое выполнение правил или информирование и общие рекомендации организации чаще применяют на практике для обеспечения соответствия техни-ческих решений архитектуре. В частности, опрос, проведенный в 2003 году ком-панией Gartner среди финансовых организаций, показал, что примерно 50-60% организаций реализуют механизмы жесткого контроля за соблюдением предпи-саний архитектуры. Примерно 20-25% используют такие механизмы как общие рекомендации, при этом подразделения несут дополнительные затраты, связан-ные с несоответствием проектов утвержденной архитектуре. Только в 15-25% организаций архитектура носит рекомендательный характер, и невыполнение рекомендаций не имеет никаких явных организационных последствий. Среди методов воздействия и контроля отметить можно следующие: «достаточно высокий» мандат, выданный группе, отвечающей за архитектуру; право подпи-сывать спецификации; право осуществления периодических проверок во время цикла разработки. Среди методов влияния используются такие, как обучение представителей подразделений, более высокая плата, которая взымается с бизнес-подразделе-ний при внедрении несогласованных с архитектурой решений и более высокая стоимость сопровождения таких решений (вплоть до отказа в поддержке), уча-стие представителей бизнеса в работе организационных структур, отвечающих за архитектуру. Эти замечания, касающиеся методов управления, контроля и надзора за архитектурой, подводят естественным образом к обсуждению в самых об-щих чертах организационных структур, в той или иной степени вовлеченных в архитектурный процесс, наряду с собственно командой проекта разработки архитектуры. Рисунок 1.11 отражает наиболее важные организационные структу-ры и связи между ними. Важно понимать функции и характеристики каждой представленной здесь организационной структуры.  Рис. 1.11. Организационная структура управления разработкой архитектуры предприятия При этом точное название подразделений и количество людей в них не не-сут принципиального значения. На самом деле, большинство департаментов ИТ уже имеют многие из этих организационных структур в той или иной форме. Все эти организационные структуры вовлечены как в процессы разработки архитек-туры, так и в процессы контроля и надзора. Управляющий исполнительный комитет является авторитетным орга-ном, который стоит за всей работой, связанной с архитектурой. В идеале он дол-жен включать представителей бизнеса и руководителей ИТ. Он задает общую стратегию и обеспечивает то, что архитектура принимает «силу закона» в орга-низации. Важный аспект заключается в том, что придавать архитектуре силу за-кона (т.е. выполнять «полицейские» функции) те люди, которые разрабатывают архитектуру (команда разработки Архитектуры предприятия), не должны: они только дают рекомендации. Архитектуру как «закон» реализует внешний по от-ношению к команде разработчиков орган, которым и является Управляющий ис-полнительный комитет. Он не занимается детальными вопросами, но оставляет за собой право принятия решений, касающихся стратегических моментов, круп-ных проектов и закупок. Он также делегирует своих членов для работы в архи-тектурном комитете, который принимает решения более низкого уровня. В круп-ных организациях могут создаваться подкомитеты и рабочие группы по отдель-ным проблемам, связанным с архитектурой. Группа управления корпоративными проектами отвечает за контроль ведения проектов, использование ресурсов, обоснование инвестиционных рас-ходов, контроль за расходованием бюджета и зависимости между проектами. В конце концов, практическая реализация архитектуры осуществляется через проекты. Группа управления проектами помогает Управляющему исполнитель-ному комитету в расстановке приоритетов и распределении ресурсов между различными проектами. Она также играет ключевую роль в обеспечении рас-смотрения и утверждения проектов, в том числе на соответствие архитектуре. Команда разработки Архитектуры предприятия отвечает за весь про-цесс в целом: подготовку всех документов, связанных с описанием архитектуры, контроль инфраструктурных проектов. Она должна представлять ключевые до-кументы, такие как описание общего видения архитектуры и концептуальная ар-хитектура, на рассмотрение и утверждение Управляющего исполнительного ко-митета и Совету по архитектуре. Она также создает отдельные команды, отвеча-ющие за разработку архитектуры отдельных доменов. Эта группа должна эффек-тивно информировать и консультировать подразделения организации по вопро-сам, связанным с Архитектурой предприятия. Следует отметить, что существенные изменения в Архитектуре предприя-тия происходят примерно каждые два года (в то время как небольшие измене-ния - каждые полгода). Команда разработки архитектуры отвечает за реализа-цию этих изменений и, возможно, за создание специальных рабочих групп по внесению таких существенных изменений (либо это делегируется командам, от-вечающим за отдельные домены архитектуры). Совет по архитектуре отвечает за предоставление вводной информации, рассмотрение и утверждение концептуальной архитектуры и других компонент архитектуры, включая стандарты на продукты. Команды разработки архитектуры отдельных доменов отвечают за формулирование архитектурных принципов, стандартов на продукты, конфигу-рации и обсуждение вопросов, связанных с отдельными доменами архитектуры (бизнес-архитектура, архитектура информации и т.д.), планирование и выпол-нение проектов, имеющих отношение к соответствующим частям архитектуры. Таким образом, постоянная работа непосредственно над архитектурой с организационной точки зрения ведется как бы на трех уровнях:
С практической точки зрения, архитектура реализуется постепенно и по-ступательно через выполнение отдельных проектов. Типичная ситуация выгля-дит так:
Отдельные программы и проекты должны соответствовать принятой архи-тектуре предприятия для того, во-первых, чтобы были реализованы желаемые преимущества с точки зрения бизнеса, а во-вторых, для того, чтобы системы и процесс разработки программных решений использовали преимущества от ра-нее выполненного анализа. Более того, как и любая архитектура, архитектура предприятия требует постоянного сопровождения, особенно в тех областях, ко-торые связаны с физическими областями, такими как технологические стандар-ты. Благодаря этому, архитектура предприятия остается актуальной и продол-жает соответствовать требованиям бизнеса по мере его изменения. Очевидно, что разработка архитектуры предприятия не будет иметь эффек-та, если организация не сможет обеспечить контроль за ее реализацией - с уче-том, однако, возможных обоснованных отклонений, как это отмечалось выше. Для этого можно применить подход, предложенный в публикациях Giga Group, где предлагается модель, которая обеспечивает классификацию архитектурных решений в соответствии со стратегическим позиционированием каждого решения так, как это показано на рис. 1.12.  Рис. 1.12. Модель рассмотрения архитектуры от Giga Group Ядро архитектуры (центральная зона) - это те архитектурные решения, технологии, стандарты, которые в данный момент времени приняты организаци-ей в качестве стратегических. Запретная зона (внешняя зона) определяет список технологий, продуктов, средств разработки, которые не должны использоваться внутри организации, ее департаментами, ни в каких проектах. Область обсуждаемых возможностей (средняя зона) находится между ядром архитектуры и запретной зоной. Эта та область, которая, возможно, по-ка не описана в существующем варианте архитектуры и в которой допустимо обсуждение вариантов решений и используемых технологий. В этой области могут также находиться технологии, используемые для пилотных проектов, на основе которых впоследствии будет принято решение: включать ли техноло-гию в качестве составной части ядра архитектуры, поместить ли ее в запрет-ную зону либо оставить где-то на границе зеленой и желтой зон в качестве тактического решения. После того, как архитектура предприятия утверждена руководством, со-трудники ИТ-службы, ответственные за планирование инвестиций, должны сле-довать ей и придерживаться ее. Предлагаемые инвестиции и изменения в уже существующих системах, когда это требуется, имеют один из 4-х возможных результатов:
В этом плане архитектура в отношении построения новых систем играет ту же самую роль, что и диета для личного здоровья человека. Здоровая диета, точ-но так же как архитектура, накладывает определенные ограничения. Финальным продуктом использования архитектуры предприятия являются дизайн эффек-тивно работающих систем и приложений. Финальным результатом диеты являет-ся улучшение здоровья человека. Более развернутые рекомендации по контролю соответствия содержатся в модели TOGAF, где описаны два основных процесса:
На практике в соответствии с моделью TOGAF возможно несколько вариантов соответствия реализации архитектуры ее описанию (рис. 1.13). В идеале, помимо «полного соответствия» разрабатываемой системы суще-ствующей версии спецификаций, необходимо учитывать такие аспекты, как:
Оценка влияния архитектуры обычно реализуется путем формирования так называемой проектно-ориентированной перспективы архитектуры, т.е. части спе-цификаций, имеющих отношение к данному проекту. Ее назначение состоит в том, чтобы представить руководителю и команде проекта на как можно более ранних стадиях релевантную информацию, которая может быть актуальна для разработки.  Рис. 1.13. Возсможные соотношения между реализацией и описанием архитектуры по TOGAF Проверка проекта на соответствие архитектуре производится, как правило, на достаточно глубоком уровне детализации в рамках предварительно опреде-ленной формальной процедуры. Ее основными целями являются:
Очевидно, что момент времени, выбранный для проведения такой провер-ки, должен являться определенным компромиссом. С одной стороны, должна быть достигнута определенная степень проработки проектных решений, и сфор-мирован набор проектных артефактов для проверки, с другой - необходимо иметь запас времени для корректировки возможных ошибок. Как правило, про-ведение такой процедуры должно предусматриваться в календарном плане про-екта. В описании TOGAF приводятся примеры опросных анкет, включающих такие об-ласти, как аппаратное и программное обеспечение, программные сервисы, уп-равление информацией и данными, безопасность, управление системами и сис-темный инжиниринг, а также даются общие рекомендации по реализации про-цедуры в целом и проведению интервью с членами команды проекта. Понятно, что в реальной работе рано или поздно в результате проверки како-го-либо проекта будет выявлено несоответствие принятой архитектуре и встанет вопрос о том, что делать дальше. Сами по себе стандарты и спецификации не долж-ны являться догмой, так что на практике отклонения от архитектуры будут допусти-мыми, если автор сможет продемонстрировать очевидную ценность предлагаемого нестандартного варианта для бизнеса - с учетом долгосрочных последствий, об-щей стоимости владения и появления новых возможностей. С другой стороны, неоправданное в этом смысле отклонение от существующей архитектуры должно приводить к определенным организационным решениям, в том числе, и по поводу финансирования проекта - иначе теряется смысл разработки архитектуры. Безусловно, возникают два вопроса, касающиеся финансовых затрат, свя-занных непосредственно с разработкой и последующим сопровождением Архи-тектуры предприятия (обновлением и поддержанием ее в актуальном состоя-нии). Сколько средств необходимо выделять на это? Как оценивать уровень за-трат на архитектуру? Размеры и характер деятельности организации, а также масштабы преобра-зований и модернизации диктуют глубину и степень детализации проработки ар-хитектуры и ее поддержания в актуальном состоянии. Соответственно это-му определяются и те ресурсы, которые необходимы для инвестиций в архитекту-ру. При этом здесь можно говорить только о затратах, связанных с разработкой самой архитектуры. Это не включает затраты на ее реализацию, такие как закупка и раз-работка программного обеспечения, закупка аппаратного обеспечения и т.д. На самом деле, на этот счет отсутствуют детальные и точные данные. По оцен-ке Gartner, в большинстве организаций вопросами разработки архитекту-ры и стратегического планирования в области ИТ занимаются обычно 2-4% пер-сонала ИТ-служб. Кроме затрат на персонал, дополнительные расходы связаны с приобретением средств моделирования и созданием репозитария для хранения артефактов (документов, моделей и пр.), описывающих Архитектуру предприятия. Во-первых, необходимо учесть размеры первоначальных затрат, связанных с инициированием архитектурного процесса: обучение, подготовка обоснова-ния необходимости создания архитектуры предприятия, создание структур уп-равления и контроля. Эти траты вряд ли будут превышать примерно 50%. после-дующих ежегодных затрат на поддержку Архитектуры. Текущие затраты на сопровождение Архитектуры включают:
Все это имеет отношение как к коммерческим, так и к государственным ор-ганизациям. |
Похожие:
 | Программа дисциплины ит-инфраструктура предприятия Компоненты архитектуры информационных технологий (ИТ). Процессы управления ит. Бизнес-архитектура. Архитектура инфраструктуры. Понятие... | | Программа дисциплины ит-инфраструктура Компоненты архитектуры информационных технологий (ИТ). Процессы управления ит. Бизнес-архитектура. Архитектура инфраструктуры. Понятие... |
| Программа дисциплины «Архитектура предприятия» для направления 080500. 62 «Бизнес-информатика» Программа предназначена для преподавателей, ведущих данную дисциплину, учебных ассистентов и студентов направления подготовки 080500.... | | Программа дисциплины «Современные erp-системы» «Теория информационных технологий и систем», «Архитектура корпоративных информационных систем» а также иметь представление о современных... |
| Инновационно-инвестиционная деятельность в электронном бизнесе преподаватель... Архитектура предприятия (продвинутый уровень). Управление электронным предприятием |  | Предпринимательская деятельность Руководитель предприятия. Отношения руководителя предприятия и собственников предприятия |
| Управление доходами и рентабельностью предприятия Доходы и расходы предприятия влияют на финансовый результат предприятия, целью же любого предприятия является получение прибыли.... | | Тема урока Колич часов Введение в искусство архитектуры. Архитектура и среда. Архитектура и ее функция в жизни человека |
| Рабочая программа Основной образовательной программы (ооп) Специальность 270301 «Архитектура» «Архитектура, специализация «Дизайн интерьера», утвержденных Министерством образования РФ 29 апреля 2002 г., №20-2902 – Б | | Реферат Основной целью дипломной работы, является применение процедуры... Ооо «Орион». В связи с поставленной целью проводится анализ показателей финансового состояния предприятия. Рассчитываются показатели... |
| Реферат «архитектура древнего рима» Связанная в своем развитии с постоянно меняющимися материальными потребностями человека, с развитием науки и техники, архитектура... | | Содержание Введение 3 Заключение 5 Список литературы 6 Эффективное управление оборотными средствами предприятия имеет огромное значение для достижения максимально возможного уровня прибыльности... |
| Рабочая программа Учебной дисциплины архитектура предприятия для... Программа составлена в соответствии с Федеральным государственным образовательным стандартом высшего профессионального образования... | | Реферат по курсу: Архитектура вс на тему: Архитектура квантовых компьютеров Квантовые компьютеры на основе молекул органических жидкостей с косвенным скалярным взаимодействием между ними и методов ядерного... |
| Реферат по курсу: Архитектура вс на тему: Архитектура квантовых компьютеров Квантовые компьютеры на основе молекул органических жидкостей с косвенным скалярным взаимодействием между ними и методов ядерного... | | Программа дисциплины «Архитектура предприятия» для направления 080500. 62 «Бизнес-информатика» Программа предназначена для преподавателей, ведущих данную дисциплину, учебных ассистентов и студентов направления 080500. 62 «Бизнес-информатика»... |
