Что такое визуальное конфигурирование
Значение слова «конфигурирование»
конфигури́рование
2. особый логико-методологический прием, мыслительная техника синтезирования разнопредметных знаний, различных представлений об одном и том же объекте
Делаем Карту слов лучше вместе
Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!
Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.
Насколько понятно значение слова длиннополый (прилагательное):
Синонимы к слову «конфигурирование»
Предложения со словом «конфигурирование»
Понятия, связанные со словом «конфигурирование»
Отправить комментарий
Дополнительно
Предложения со словом «конфигурирование»
Кроме того, существует возможность управления доступом к отдельным папкам и дискам. Windows 2000 позволяет управлять возможностью конфигурирования системы установкой новых программ.
Мы не будем подробно останавливаться на вопросах конфигурирования программы – это слишком глубокая тема, которая достойна отдельной книги.
Он назначается администратором во время конфигурирования сети.
Обучение программированию на 1С
Первые шаги в конфигурировании 1С для чайников
Начинающие программисты в 1С знают, как сложно найти понятную информацию о конфигурировании 1С и обучении для новичков. Даже опытные пользователи программы первый раз открыв конфигуратор растеряются: форма подачи информации здесь иная. Нужно знать интерфейс Конфигуратора 1С, чтобы начать ориентироваться в составе дерева конфигурации.
Дерево конфигурации: создаём, редактируем, удаляем
Обучение программиста конфигурированию в 1С начинается с запуска программы в режиме конфигуратора. Для чайников: Конфигурация – жмём «Открыть конфигурацию» – получаем дерево, состоящее из объектов Конфигурации.
Перед нами объекты конфигурации: справочники, константы, документы и отчёты. Используя объекты конфигурации можно создавать, вносить изменения и удалять элементы дерева. Для поиска нужного объекта, можно воспользоваться возможностями поиска по первым буквам. Объекты имеют свой интерфейс.
Пользовательский интерфейс содержит формы списка, формы записи объекта и формы выбора.
Создание и конструирование: управляемые формы в Конфигурации 1С
Важно осознавать, что любая команда пользователя об изменении данных объекта передаётся через форму. Формы позволяют вносить новые данные, корректировать информацию, удалять ошибочные данные. В программе 1С программист фактически сообщает системе, как управлять размещением объектов в форме, как группировать элементы, каким должен быть порядок расположения. Если писать инструкцию для чайников, то фактически нужно:
Можно изменять по своему желанию не только расположение элементов, но и её внешний вид: достаточно воспользоваться функционалом такого инструмента, как: «Свойства элементов формы».
Открытие форм для редактирования
Для просмотра формы и её редактирования можно использовать как простое открытие, так и открытие формы с предварительно установленным отбором. При этом из всего числа выделяются конкретные параметры. Достичь этого можно либо установив отбор, либо используя параметризированные команды.
Изучение синтаксиса языка 1С: от простого к сложному
На курсах программирования 1С для чайников начинают с самых азов языка. Несколько академических часов, уроки в формате видео-курсов помогут стать уверенным разработчиком 1С. Что нужно знать новичку в конфигурировании 1С?
Важно понять изначально, что программа 1С – это очень гибкая система, которую нужно настраивать. Конфигурирование 1С позволит решить практически любые бизнес-задачи, относящиеся к сфере автоматизации процессов. Алгоритм работы описывается встроенным языком 1С. Его функционал прост, инструкция работы в конфигураторе «для чайников» позволит использовать его объектно-ориентированные возможности для доступа к справочникам и документам.
Разработка прикладных решений
Платформа 1С позволяет модифицировать прикладные решения на базе основного продукта. Для начала работы необходимо иметь следующие навыки:
Специально для обучения начинающих программистов 1С мной было разработано руководство по программированию в системе 1С:Предприятие. Скачивайте и читайте более подробно как изучить 1С!
Цикл статей по основам Software Configuration Management
Пролог
Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.
Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.
А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.
Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.
Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.
Что такое CM и зачем он нужен
Управление конфигурацией
Для начала определимся, что такое configuration, ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».
В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.
Версия – это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.
Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.
В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).
Схема 1. Элементы, их версии и срезы-конфигурации.
CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.
Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.
Так в чем же заключается такая ценность CM?
Направления ответственности CM
Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.
Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.
Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.
Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.
Средства контроля изменений и обеспечения версионности создают условия для распараллеливания разработки в больших командах. Это достигается благодаря тому, что, описав эти средства, мы даем разработчикам документированные процедуры, позволяющие разделять ответственность и ограничивать области деятельности каждого из разработчиков.
Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.
Итак, каковы задачи управления конфигурацией?
Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.
Конфигурирование или адаптация?
Анализ функциональных возможностей, предлагаемых на рынке решений, зачастую приводит к выводу, что ни одно из них не удовлетворяет всем требованиям заказчика, и нередко требуется внесение изменений путем конфигурирования или адаптации. Однако не следует забывать про скрытые затраты, которыми чревато применение этих технологий.
Конфигурирование и адаптацию программного обеспечения по смыслу часто путают— оба термина нередко используют как синонимы, когда речь идет о модификации ПО для его соответствия специфическим требованиям заказчика. Программное обеспечение можно назвать конфигурируемым, если его можно настроить через стандартные интерфейсы без программирования дополнительных функций и/или без изменения исходного кода программы. Если требования к системе нельзя удовлетворить без программирования или изменения исходного кода, то программное обеспечение принято называть адаптируемым.
Важным аспектом, отличающим конфигурирование от адаптации, является существенная разница в требуемых ресурсах и уровне компетенции персонала для достижения нужного результата. Адаптация готового решения требует значительно больше ресурсов, причем не только в момент внесения изменений, но и в течение всего жизненного цикла решения.
Возможности системы автоматизации службы поддержки определяются рыночным спросом— если спрос на определенную возможность продукта достаточно высок, производители будут такую возможность разрабатывать для своих решений, и она очень быстро получит распространение на рынке как «стандартная» функция; а если требование не пользуется массовым спросом, то соответствующие функции разрабатываются таким образом, чтобы их можно было поддерживать с помощью дополнительных изменений и настроек, что потребует от пользователя дополнительных расходов. Если же требования к функциональности уникальны, то маловероятно, что пользователь сможет найти уже имеющееся решение, поэтому реализация будет существенно отличаться от возможностей готового (out-of-the-box) продукта. На модификацию в соответствии с требованиями уникальных спецификаций потребуется больше усилий квалифицированных специалистов и неизбежно затраты на реализацию будут выше.
Подходы к настройке и адаптации функциональности ITSM-платформы
Можно выделить шесть основных способов, с помощью которых путем конфигурации и адаптации готовое приложение можно превратить в требуемое решение.
Подбор готовых модулей и компонентов. Этот способ предусматривает выбор одного или нескольких компонентов из набора модульных решений, каждое из которых реализует определенную функциональность так, чтобы сформировать общее решение, «наилучшим образом» отвечающее требованиям клиента.
Настройка пользовательского интерфейса, прав доступа и бизнес-логики. Большинство корпоративных ITSM-решений включают в себя инструментальные средства конфигурации пользовательского интерфейса, права доступа и логики,— это позволяет достигнуть гибкости, необходимой для удовлетворения требований клиента без программирования скриптов, дополнительного кода и глубоких технических знаний. Такой подход предусматривает моделирование последовательности заданий и бизнес-логики, создание и изменение форм пользовательского интерфейса, поддержку прав доступа и «придание» продукту определенного внешнего вида.
Модификация структуры метаданных. В этом случае структура готовой базы данных меняется таким образом, чтобы она лучше соответствовала требованиям, предъявляемым к данным в конкретной организации: добавление новых таблиц, изменение типов данных, установка атрибутов данных.
Использование встроенной среды разработки. Такая среда занимает промежуточное положение между инструментами настройки и полномасштабной разработкой программного обеспечения. Некоторые решения предоставляют интегрированную среду разработки, в рамках которой пользователь с помощью внутреннего языка программирования может разрабатывать специальные клиентские инструменты.
Разработка с использованием программных интерфейсов. Некоторые из ITSM-решений предоставляют стандартизованные программные интерфейсы (API), применяемые для создания дополнительной функциональности и реализации особенностей работы программного обеспечения за счет прямого обращения к функциональности базовых данных и исходного кода без модификации базовой системы. Это может быть выполнено с помощью привлечения профессиональных разработчиков и является затратным решением как с точки зрения разработки, так и с точки зрения сопровождения готового решения.
Модификация программного кода. Способ предусматривает прямую трансформацию исходного кода для добавления или изменения функциональности системы. Это может быть сделано производителем или пользователем и является самым дорогим и технически сложным методом.
Последствия конфигурирования и адаптации
Любые модификации имеют свои последствия— внесение изменений в готовое решение путем конфигурации и адаптации влияет на затраты, сроки внедрения, функционирование, обслуживание, модернизацию и поддержку продукта. Внедрение системы автоматизации будет отложено на время внесения изменений, причем финансовые потери будут определяться двумя факторами— увеличением затрат, необходимым для модификации продукта, и сдвигом сроков возврата инвестиций (ROI), на фоне того, что лицензии уже приобретены.
Рост операционных расходов и расходов на сопровождение зависит от сложности конфигурации и адаптации. Чем более существенные изменения вносятся в стандартную платформу ITSM, тем больше будут расходы на сопровождение на протяжении всего жизненного цикла продукта. Также нельзя игнорировать возникающую зависимость от качества поддержки адаптированного решения со стороны разработчиков уникального решения.
Адаптация— одна из самых часто упоминаемых причин сбоев в работе программного обеспечения. Технические сбои мешают максимально эффективно использовать решение, которое превращается в расходную часть (пассив), а не в актив. В бизнесе время— деньги, поэтому в результате адаптации программного обеспечения операционные расходы в расчете на звонок в службу поддержки зачастую будут расти, а не снижаться.
С одной стороны, инструментарий службы поддержки необходимо выбирать таким образом, чтобы можно было гарантировать постоянное соответствие этих служб меняющимся бизнес-требованиям. Однако и сами модификации, и их последующие изменения на протяжении всего жизненного цикла продукта также приводят к увеличению затрат. Кроме того, модификации напрямую влияют на поддержку продукта у производителя. У заказчика возникают сложности с поддержкой адаптированных решений, поскольку развитие готового продукта поставщиком не согласовывается с адаптированным решением.
Модернизация адаптивных решений, как правило, требует значительных усилий. Если производитель или внешний разработчик не учитывает необходимость последующих модернизаций, маловероятно, что все изменения инструментария, сделанные в результате конфигурации и адаптации, будут автоматически переноситься на новую версию. И когда эти модификации не сопровождаются необходимой документацией, вполне возможно, что придется проводить аудит всех адаптаций, прежде чем начать вручную переносить модификации в новую версию— а это достаточно длительный и дорогостоящий процесс. Масштаб такого проекта не следует недооценивать, и во многих случаях выгоднее заняться поиском на рынке альтернативных решений.
Когда необходимы изменения готового решения?
С точки зрения бизнеса, следует просто выделить нужную сумму на реализацию конкретной возможности службы поддержки. При этом самый надежный способ гарантировать, что расходы никогда не превысят ценности решения,— это убедиться, что вся функциональность реализована в готовом инструментарии. Не стоит рассчитывать на то, что готовый продукт будет отвечать всем требованиям, однако необходимо быть уверенным в том, что «небольшое количество жизненно важных» требований, на долю которых придется 80% всей пользы от продукта, можно получить без модификации. Важно четко представлять, какая функциональность имеется в исходном продукте, а что должно быть реализовано за счет конфигурации и адаптации. В тех случаях, когда это возможно, лучше выбрать инструментарий, в котором оставшиеся обязательные требования можно удовлетворить с помощью инструментов конфигурации, а не за счет адаптации. Это нужно для минимизации количества требований, выходящих за рамки готовой функциональности— известно, что формулировка «нам это нужно» на самом деле означает «было бы неплохо это иметь». Не каждое требование можно рассматривать как обязательное, поэтому необходимо, чтобы в компании была принята политика, в соответствии с которой все требования, предполагающие затратную адаптацию продукта, подтверждались с точки зрения их необходимости для бизнеса. Такая политика позволит минимизировать общую стоимость владения в течение жизненного цикла продукта. Важно задать себе два вопроса: насколько действительно нужна эта возможность и есть ли риск, что стоимость реализации этой функциональности превысит эффект от ее применения?
Каждое требование, которое может быть выполнено за счет использования функций готового продукта, «оплачивается» из суммы, потраченной на покупку лицензии, и существенно экономит общие затраты. Предположим, что инструментарий службы поддержки должен соответствовать 100 требованиям, 80 из которых выполняются в готовом решении, а 20 необходимо реализовать дополнительно. Пусть лицензионные затраты составляют 2000 долл. на пользователя в год, в таком случае стандартное требование в расчете на пользователя будет стоить 25 долл.
Предположим, что средние затраты на изменения составят: а) на реализацию одного требования с помощью конфигурации— 50 долл, что равняется примерно 2-4 часам работы администратора системы; б) на реализацию одного требования с помощью адаптации— 1 тыс. долл., что составляет примерно 1-2 дня работы разработчика системы. В таком случае, если 20 требований можно на 50% выполнить с помощью конфигурации, а на 50% с помощью адаптации, то вы можете добавить к общей сумме 500 долл. за изменения путем конфигурации и 10 тыс. долл. за изменения путем адаптации. Если у продукта 20 пользователей, и в течение первого года нет необходимости в дальнейших изменениях, то затраты за первый год (исключая расходы на услуги реализации) составят 50500 долл. против 40 тыс. Это на 25% больше, чем если бы готовое решение изначально соответствовало всем требованиям. Кроме того, при отсутствии должного управления, по мере увеличения срока использования продукта те изменения, которые внесены в результате его адаптации, могут вызвать экспоненциальный рост расходов.
Для каждого конкретного набора инструментальных средств необходимо выяснить, каким функциональным требованиям удовлетворяет готовое решение, а какие можно выполнить за счет конфигурации или адаптации. Стоит с осторожностью стремиться к тому, чтобы про созданное решение можно было сказать, что «наш продукт может делать все». Гибкость никогда не дается бесплатно. Также важно помнить, что серьезная адаптация решения может иметь далеко идущие последствия— это повлияет на отдачу от инвестиций на всех этапах жизненного цикла продукта, от реализации и использования до поддержки и модернизации. Необходимо расставить приоритеты требований с учетом их цены и пользы для бизнеса, а не в зависимости от того, кто выдвигает эти требования и насколько настойчиво. Как правило, 80% ценности инструментария службы поддержки приходится на 20% его функциональности. Стоит ли тратить 250% от стоимости готового решения на то, чтобы добиться выполнения оставшихся 20%?
Как избежать столь высоких затрат на модификацию стандартных решений, предлагаемых на рынке? Выход— использование продуктов «out-of-the-box», концепция разработки которых изначально опирается на стандарты, такие как ITIL.
ITIL как средство стандартизации
Решения, построенные по принципам ITIL, обладают следующими возможностями:
Подобный комплексный подход к развитию и техническому сопровождению позволяют свести к минимуму затраты на конфигурацию и/или адаптацию готового решения. Желательно также, чтобы компания, принявшая решение о внедрении новых или совершенствованию уже существующих ИТ-процессов, получала доступ к лучшим практическим решениям по автоматизации управления и сопровождению ИТ в своей отрасли. Такой подход позволит избежать типовых ошибок и сэкономить время на решении известных проблем.
Одним из примеров реализации концепции «out-of-the-box» является предлагаемый компанией Axios Systems продукт assyst (см. рисунок), основанный на ITIL v3. Заказчику не нужно быть специалистом по ITIL, чтобы воспользоваться преимуществами процессного подхода и функциональностью assyst— это продукт, готовый к внедрению в организации и позволяющий свести к минимуму необходимость конфигурации и адаптации. Решение assyst изначально создавалось таким образом, чтобы его можно было использовать при постоянно изменяющихся бизнес-требованиях.
Рисунок. Интеграционная архитектура assyst
Специфические детали описания бизнес-среды каждой компании хранятся в центральной базе данных, что гарантирует согласованность и актуальность информации. Такая база разделена на блоки данных (Customer Service Groups), предназначенные для конкретных рабочих групп, что позволяет одной системе обслуживать единые ИТ процессы в различных подразделениях, или обслуживать отличающиеся ИТ подразделения разных компаний. Это дает преимущества для провайдеров сервисных услуг и позволяет предоставлять услуги аутсорсинга различных процессов для нескольких заказчиков одновременно. В решении изначально интегрированы процессы ITIL используются известные, опробованные заранее процедуры, шаблоны, формы и подпроцессы, что существенно снижает затраты на доработку системы.
Портал самообслуживания assystNET дает возможность конечным пользователям регистрироваться в системе через Web, сообщать о своих инцидентах и отслеживать процесс их решения. Благодаря этому экономятся ресурсы первой линии службы поддержки и увеличивается эффективность работы. Ключевой особенностью решения «out-of-the-box» является возможность настройки внешнего вида портала с помощью встроенных средств конфигурации без кодирования, возможность использования отдельного Web-интерфейса под каждого заказчика.
Возможности assyst по интеграции и обмену данными обеспечиваются благодаря специализированным модулям, адаптерам, коллекторам, шлюзам, позволяющим интегрировать решение IT Service Management assyst с любым внешним приложением или источником данных (см. рис.). Интеграционная платформа позволяет организовать любой способ обмена данными: одно- и двунаправленный, событийный, по расписанию, от самых простых вариантов запуска внешних приложений до глубокой интеграции приложений с помощью встроенного API. Assyst позволяет обмениваться релевантной информацией с другими ITSM-системами, внешними системами мониторинга и сбора информации об ИТ-инфраструктуре.
Хеерко Груневеген (heerco.groenewegen@axiossystems.com) — вице-президент по развитию бизнеса компании Axios Systems.
Успех применения систем типа Axios assyst определяется особенностями их адаптации и конфигурирования для нужд конкретного заказчика— без учета тонкостей российского ИТ-рынка вообще и сектора решений для организации и автоматизации служб технической поддержки, в частности, инвестиции в решения управления ИТ будут неэффективны.
Конфигурирование и адаптация программного обеспечения предполагают наличие у заказчика некоторого готового программного решения (системы), в той или иной степени отвечающего его требованиям по различным критериям: стоимость лицензий, стоимость внедрения, функционал, стоимость последующего сопровождения и т.п. Несмотря на то, что сегодня преобладает тенденция использования готовых решений, стоит помнить и о том, что у заказчика всегда есть выбор— использовать уже имеющееся решение (путем его конфигурации или адаптации) либо создать собственное, заказав его разработку своему ИТ-подразделению или обратившись к внешнему разработчику.
В секторе решений для организации служб технической поддержки, конечно, повсеместно используются готовые системные решения различной степени сложности и функциональности. Необходимо отметить, что данные решения состоят не только из выбора системы автоматизации для реализации требований заказчика и последующего ее внедрения, а еще включают в себя предварительное обследование, анализ, построение организационно-процессной части решения и формализацию требований к системе автоматизации. Безусловно, стандартом «де-факто» по построению ИТ-процессов и организации служб технической поддержки ИТ является сегодня библиотека ITIL, однако в ней нет четких требований и вариантов построения процессов. Предполагается, что заказчик самостоятельно или при помощи внешних консультантов выстроит процессы в соответствии со своими требованиями, рекомендациями ITIL, внутренней культурой и экспертизой организации. В этом случае вопрос выбора системы автоматизации остается важной и ответственной частью решения, который априори будет решаться с учетом действительно важных, отфильтрованных и ранжированных по приоритетам требований заказчика, дав ему возможность более свободно ориентироваться в различных системах, а также в вопросах сравнения подходов к внедрению систем (конфигурация или адаптация).
Продукт аssyst представляет собой сбалансированное решение, позволяющее при необходимости достаточно быстро автоматизировать процессы ITIL в службе технической поддержки ИТ за счет богатого функционала. В системе заложена большая вариативность и конфигурируемость автоматизируемых процессов, причем основная часть потенциальных вариантов конфигурации процессов взята из рекомендаций ITIL, и это снижает риски, возникающие при постановке задач и формализации требований к системе.
Георгий Ованесян (croc@croc.ru), руководитель направления технической поддержки и аутсорсинга компании Крок (Москва).
Поделитесь материалом с коллегами и друзьями