какие существуют три важных направления развития и использования информационных систем
Тема 3. Информационные системы в экономике
Цель:
Дать представление об экономических информационных системах и обрабатываемых в них данных. Определить основные принципы построения и использования автоматизированных систем во внешнеэкономической деятельности.
Задачи:
Оглавление
1. Информационные системы в экономике
1.1. Роль и место автоматизированных информационных систем в экономике
Современные информационные системы реализуются главным образом в виде прикладных процессов. Это обстоятельство согласуется с базовой моделью информационных систем, предложенной международным стандартом ISO (International Standards Organization). В ней отмечаются три логические части:
Прикладные процессы характеризуются большим набором функциональных блоков, обеспечивающих совместную работу пользователей информационной системы через область их взаимодействия и физические средства соединения системы.
В тех случаях, когда прикладные процессы предназначены для решения экономических задач, следует говорить об информационных экономических системах. Они охватывают все виды и формы деятельности, начиная от моделей экономического развития государства и кончая бухгалтерским учетом предприятия фирмы.
Рассмотрим три важных направления развития и использования информационных систем:
Информационные системы предпринимательства представляют собой комплекс технических и программных средств для обеспечения предпринимателей инструментом правильного принятия решений. Информационные системы предпринимательства отличаются большой сложностью и требуют сбора разнообразной информации, разработки стратегии действий, проведения маркетинга, финансовых расчетов, планирования и т. д. Особенностью этих систем является то, что все сказанное раньше должно выполняться в течение достаточно короткого промежутка времени, чтобы гарантировать получение максимального дохода. Известно, что запоздавшая информация может привести к принятию неправильного решения и банкротству фирмы.
Информационные системы менеджмента представляют собой комплекс технических и программных средств, обеспечивающих менеджеров фирм информацией для правильного принятия решений. Информационные системы менеджмента охватывают широкий круг задач управления производством, торговлей и персоналом. Они опираются как на средства Интернета, так и на организацию средств Интранета на предприятии.
Банковские информационные системы представляют собой комплекс технических и программных средств для обеспечения банковских работников информацией при выполнении ими финансовых и учетных операций.
Банковские информационные системы опираются на получающие все большую популярность электронные деньги. С их помощью реализуются банковские технологии. Самой большой международной банковской системой является сеть SWIFT. Она представляет собой открытую систему, допускающую внедрение однотипных прикладных процессов для решения все новых и новых задач. Сейчас SWIFT объединяет более 7000 банковских систем, расположенных почти в 100 странах, в том числе и России.
При разработке банковских информационных систем требуется обращать особое внимание на надежность их функционирования и безопасность данных. Даже незначительный аппаратурный сбой может привести к непоправимым последствиям. А защита банковской информации от несанкционированного доступа рассматривается на всех уровнях банковской системы.
В последнее время активное развитие получает направление разработки корпоративных систем, которые средствами Интранета объединяют информационные системы подразделений, филиалов, дочерних предприятий в единую информационно-вычислительную сеть.
На рис. 3.1 приведена обобщенная схема информационной системы, показывающая основные объекты системы и связи между ними.
Основным объектом системы является Производство, где образуется большое количество информации – производственной, экономической, управляющей. Она передается другим объектам системы – подразделениям. Измерение, накопление и передача информации другим подразделениям осуществляется в настоящее время с помощью компьютеров, управляемых программами реального времени.
В Бухгалтерии накапливается, а затем хранится и обрабатывается экономическая информация, определяющая показатели Производства. Здесь на основе этих показателей планируются методы решения тактических производственных задач. Обычно используются программные средства, ведущие базы данных и позволяющие создавать различные запросы к ним. Примерами служат ПАРУС, КОМПАС, БУХТА, 1С-ПРЕДПРИЯТИЕ и др.
В Маркетинговой службе формируется информация о показателях производства, которые требуются в настоящее время и будут требоваться в ближайшем будущем. В этой службе готовятся данные для стратегического планирования, решаются задачи анализа рынка, прогнозирования выпуска продукции и т. д. Программные средства должны иметь вычислительный характер, чтобы быстро и качественно строить тренды для наборов численных данных, формировать математические модели статического и динамического вида. Например, MS Excel позволяет легко и просто построить тренды различных типов для прогнозирования.
Рис. 3.1. Обобщенная схема информационной системы
Управляющая информация формируется в Администрации. Здесь собирается и анализируется необходимая производственная и экономическая информация, осуществляется принятие решений как тактического, так и стратегического назначения. Принятие решений – основная функция Администрации. Поэтому здесь концентрируются наиболее ответственные и сложные программные продукты, помогающие администраторам подготовить и выбрать правильное решение.
1.2. Экономические информационные системы
Экономическая информационная система – человеко-машинная система, предназначенная для хранения, поиска, обработки и выдачи информации в виде данных и знаний, необходимых для управления экономическим объектом, по запросам пользователя-экономиста. Экономическая ИС представляет собой человеко-машинный комплекс, в котором экономическая информация обрабатывается с помощью компьютера, а результаты обработки используются экономистом для принятия решения.
1.2.1. Превращение экономической информации в данные информационной системы
Экономическая информация характеризуется информационной совокупностью, которая представляет собой множество данных, отражающих какую-либо сущность (явление, экономический объект). Пример. Пусть необходимо определить экономическую информацию, обрабатываемую информационной системой магазина, торгующего телевизорами. Проведя систематизацию и структурирование этой информации, необходимо сформировать данные информационной системы. Экономическим объектом описания (сущностью) в этом случае будет Продажа телевизоров. Определим для этого объекта следующие понятия: информационная совокупность, атрибут или реквизит, экономический показатель, документ и файл. На рис. 3.2 показана схема информационной совокупности сущности.
Рис. 3.2. Схема информационной совокупности сущности
Информационная совокупность – группа данных из реквизитов, экономических показателей и документов, характеризующих какой-либо объект. Реквизит – единица экономической информации, выражающая определенные свойства объекта, описываемого информацией. Реквизит состоит:
Реквизиты-основания – это групповые и справочные данные. К ним относятся плановые и фактические данные, нормативно-расценочные, расчетные данные.
Для количественных и стоимостных реквизитов обычно указывается единица измерения. Описание показателей и реквизитов какого-либо документа требует, как правило, их соотнесения с местом и временем отражаемых экономических процессов.
В нашем случае реквизиты-признаки – это Наименование: Продажа телевизоров, Место действия: магазин «Витязь», Адрес: Невский пр., 120 и т. д., а реквизиты-основания – это Цена, Выручка, Количество проданных телевизоров каждой марки, Время действия и т. д.
Экономический показатель – совокупность логически связанных реквизитов — признаков и реквизитов — оснований, имеющая экономический смысл. В нашем случае экономический показатель – это Объем продаж телевизоров определенной марки. На основе показателей строятся документы,которые могут включать в себя один или несколько показателей.
Таким образом, информация о продаже телевизоров превратилась в данные экономической информационной системы.
Для нашего примера эта схема имеет вид, приведенный на рис. 3.3, где показаны реквизиты, характеризующие качественные и количественные свойства объекта «ПРОДАЖА ТЕЛЕВИЗОРОВ». Приведены некоторые показатели экономического типа: Объем продаж телевизоров марки 1, Выручка за продажу телевизоров марки N. Документы ориентированы на определенные марки телевизоров.
1.2.2. Хранение информационных совокупностей
Хранение информационных совокупностей осуществляется в памяти компьютера. Организация хранения может быть в виде массивов либо в базах данных.
При работе с информационными системами экономического назначения в большинстве случаев приходится иметь дело с файлами. При измерении экономической информации данные собираются в числовые или текстовые файлы. Данные хранятся на носителях в виде файлов. Они передаются по каналам связи в виде файлов. Наконец, результатами обработки данных обычно являются файлы.
С помощью файлов создаются и основные пока виды экономических документов – бумажные отчеты, формы, справки. В будущем, с развитием технологии электронной подписи, обеспечения требуемой защиты файлов, доля бумажных документов будет сокращаться.
1.2.3. Классификация экономических информационных систем
Информационные системы, применяемые в экономике, можно классифицировать по следующим признакам:
2. Основные принципы построения и использования автоматизированных систем во внешнеэкономической деятельности
Автоматизированные системы (АС) создаются в соответствии с техническим заданием, являющимся основным исходным документом, на основании которого проводят создание АС и приемку ее заказчиком. Создание АС должно осуществляться на основе принципов системности, совместимости, стандартизации (унификации), развития (открытости) и эффективности.
Принцип системности заключается в том, что на всех стадиях создания и развития целостность системы должна обеспечиваться связями между подсистемами и комплексами задач. Требования к создаваемой системе должны определяться со стороны высшей по иерархии системы, включающей в себя данную АС. В создаваемой АС должна быть обеспечена связность решения отдельных автоматизированных задач системы и работы учреждения в целом. Этот принцип должен быть реализован путем создания единой подсистемы управления АС.
Принцип совместимости заключается в том, что при создании АС должны быть реализованы информационные интерфейсы, благодаря которым она может взаимодействовать с другими АС в соответствии с установленными правилами. Символы, коды, информационные и технические характеристики структурных связей между подсистемами и компонентами АС должны быть согласованы так, чтобы обеспечивалось совместное функционирование всех подсистем АС. В АС должны использоваться единые термины, символы, условные обозначения и способы представления информации во всех автоматизированных задачах, комплексах задач, подсистемах. Этот принцип требует использования в АС единой системы классификации и кодирования информации, единых правил сопоставления всех взаимосвязанных информационных показателей.
Принцип стандартизации (унификации) состоит в том, что подсистемы и компоненты системы должны быть по возможности типовыми. Этот принцип должен реализовываться путем:
Принцип развития (открытости) состоит в том, что АС должна создаваться как развивающаяся система, допускающая пополнение, совершенствование и обновление подсистем и компонентов. Этот принцип должен реализовываться за счет открытой структуры всех подсистем АС. Развитие системы будет осуществляться путем пополнения ее новыми подсистемами и компонентами, модернизации действующих подсистем и компонентов, обновления используемых средств вычислительной техники более совершенными.
Принцип эффективности заключается в достижении рационального соотношения между затратами на создание АС и целевыми эффектами, включая конечные результаты, получаемые в результате автоматизации.
Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. Стадии и этапы создания АС в общем случае приведены в российском стандарте ГОСТ 34.601-90. В качестве отдельных стадий создания АС здесь определены следующие:
В ГОСТ 34.602–89 устанавливаются состав, содержание, правила оформления, порядок разработки, согласования и утверждения документа «Техническое задание на создание (развитие или модернизацию) автоматизированной системы». Проект технического задания (ТЗ) на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.). При необходимости разработчик ТЗ и заказчик осуществляют согласование проекта ТЗ с органами государственного надзора и заинтересованными организациями. Утверждение ТЗ осуществляют руководители предприятий (организаций) разработчика и заказчика АС.
Специалисты сферы управления, экономической, финансовой и правовой сфер выступают, как правило, в процессе создания АС в роли заказчика. Роль заказчика очень велика в разработке информационного, организационно-методического, правового и эргономического видов обеспечения АС.
Информационное обеспечение АС подразделяется на внемашинное и внутримашинное и состоит из следующих компонентов:
Процесс создания АС, как правило, начинается с изучения существующих входных, внутренних и выходных информационных потоков, системы документации, системы классификации и кодирования информации, фондов информации. На основании этой работы осуществляется определение и проектирование организации и технологии работ учреждения в условиях функционирования АС, а также устанавливается необходимость использования покупных баз и банков данных АС, сетей передачи данных.
Если в процессе проектирования АС принято решение о необходимости организации информации (или части ее) в виде собственных реляционных БД, то процесс проектирования информационного обеспечения функциональных задач системы должен включать в себя построение концептуальных и логических моделей реляционных баз данных.
Уже на первых этапах создания системы должны быть приняты решения по логическому контролю входной информации системы, приданию юридической силы выходным документам системы, организационным и техническим мерам по обеспечению требований информационной безопасности.
При создании АС необходимо обеспечивать информационную безопасность и защиту информации. При работе в однопользовательской АС защита массовой внутримашинной информации, как правило, обеспечивается парольной защитой, а при работе в локальных вычислительных сетях – комплексом программных средств.
Какие существуют три важных направления развития и использования информационных систем
Пути развития ИС
Введение
Сегодня я начну тему, которая, на мой взгляд, наиболее важна в свете аспектов работы над уже внедренной информационной системой (ИС). Поднятые в ней вопросы можно успешно экстраполировать на миропонимание любого IT специалиста, который хотел бы достичь чего-то существенного в своем направлении деятельности.
Опыт, который я получаю в жизни, стараюсь все время примеривать на рабочие задачи для того, чтобы добиться наиболее комплексного и успешного решения возникающих задач. И как ни странно, это работает.
Предпосылки развития
Гармоничное сочетание теоретических знаний и практического опыта позволяют системно осмысливать происходящую ситуацию и предлагать наиболее уместное в конкретной ситуации решение. Но, рано или поздно, наступает состояние «застоя», которое заключается в том, что круг решаемых задач становится однообразным, и не происходит формирование новых подходов к решению проблем. Такая ситуация чревата тем, что специалист начинает чувствовать свою бесполезность (в этом нет ничего хорошего как для самого специалиста, так и для его работодателя). Таким образом, вопрос развития постоянно актуален. Все вышесказанное применимо и для ИС. Если ИС будет решать ограниченное количество задач на длительном интервале времени, то она станет беспомощна перед конкурентами, что приведет к её моральному и логическому устареванию, а также возможной замене на более привлекательный аналог.
Вопрос развития конкретной системы должен определяться стратегией (политикой) развития компании, в которой она функционирует, но откровенно говоря, стратегий информационного развития я видел не так много, а предприятий, которые следует этому документу, еще меньше. Да и во многих случаях следование информационной стратегии бесполезно, если вся компания не следует высокоуровневой стратегии развития всего предприятия, так как эти документы взаимоувязаны между собой. В том случае, если даже этим документам свято следует руководство компании, но на практике находится тысяча объективных причин, почему их не удается воплотить до конца. Учитывая подобные предпосылки, возникает задача определения путей направления развития ИС, исходя из реальных, «полевых» условий.
Направления развития
Ко второму типу задач подход прогноза можно применить только с большой осторожностью, кучей оговорок и пониманием того, что развитие подобных систем напрямую зависит от субъективного направления мысли, видения развития стейкхолдера того пути развития, в котором находится рассматриваемая ИС. К этому типу систем, на мой взгляд (приготовился к обороне, надел доспехи и каску 🙂 ), относится подавляющее большинство всех бизнес ИС.
Первый тип задач рассматривать нет нужды, в силу того, что есть множество научных или около научных подходов, хорошо зарекомендовавших себя, которые с успехом помогают разрешать подобные задачи и предсказывать тренд их продвижения на перспективу. Для примера будет достаточно сказать о ТРИЗ (поклонником которого является Ваш покорный слуга). Невероятно логичный инструмент, который позволяет абстрагироваться от понятия психологической инертности мышления и направить мысль в «правильное» русло.
Если область решения является логически предсказуемой и последовательной (задачи ПР), с заранее определенными или прогнозируемыми рамками решения, то объективный результат возможен. Если же речь идет о сложно прогнозируемых в плане развития системах (задачи СР), то объективный и системный подход к их решению в большинстве случаев маловероятен. Именно поэтому подобные системы и привлекают нас к себе своей алогичностью (с точки зрения системного рассмотрения объективной ситуации) и сложностью.
Сосредоточусь на втором типе задач (СР), которые, в свете их субъективной прогнозируемости, являются очень заманчивыми и интересными для исследования, а также для многих из нас представляют собой каждодневный «хлеб насущный».
Объективно о субъективном
Последовательность и логика не всегда применимы при работе с «живыми» и мыслящими пользователями. Как было показано выше, развитие любого бизнеса диктуется, прежде всего, видением его владельца. Да, что-то возможно спрогнозировать, но при этом в любой момент направление развития может быть изменено, и все выстроенные и логически спроектированные модели и гипотезы потребуют оперативной корректировки и адаптации под изменяющиеся условия.
Для любого руководителя более приоритетной является ориентация не на объективные закономерности развития внешней и внутренней среды, а на свою интуицию, базу знаний и опыт. Именно такая направленность на свои внутренние качества и позволили ему достигнуть того положения, в котором он находится (так думают 99,9% руководителей, и определенная логика в их размышлении есть). Если бы он вел себя абсолютно предсказуемо, пусть даже алгоритм его мысли был бы очень сложен, то он был бы последователен и вычислим. Вряд ли подобный руководитель отличался от программного обеспечения (ПО), что позволило бы его легко заменить автоматизированной программой, но на практике пока такого не случается. Именно личный подход к делу, проявление эмоций и придание той или иной ситуации особых эмоциональных красок не позволяют оцифровать человеческое мышление и делают его поистине уникальным, так же, как и продукты, получаемые в результате мыслительной деятельности. Поэтому при работе с бизнес системами, хозяева которых бесспорно мыслящие люди, приходится постоянно «держать ухо востро» и быть готовым к смене курса развития поддерживаемой ИС.
Выбор модели развития в проектах с типом задач СР
После внедрения бизнес ИС часто возникает проблема абсолютно неконтролируемого и алогичного (ну на взгляд последовательных и логичных специалистов) в дальнейшем развития этого самого ПО. Но, вникнув в специфику и текущие цели бизнеса, находишь в этом развитии определенную, пусть и субъективную, логику. В подобной ситуации необходимо помнить о том, что абсолютно объективного решения в задачах с высокой степенью стохастичности (а они именно такими по большей части и являются) в принципе не возможно (какая же широкая площадка для творчества наш ждёт).
Вопрос о выборе методологии развития и сопровождения внедренной информационной системы (ИС) становится наиболее актуальным для ИТ руководства компании сразу после появления первых системных проблем и запросов пользователей об улучшении функционала интегрированного в организацию ПО.
как правило, заказчики для себя отвечают перед внедрением, но вот на вопросы:
отвечают не сразу, так как считают, что ответы на них и так интуитивно понятны и определены (Зачем же мы тогда по-Вашему её внедряли?), а многие оставляют их ответы на потом, специально, чтобы не забивать себе голову подобной «ерундой».
Следуя принципам процессного управления, топ-менеджмент осознанно или бессознательно, после внедрения системы и решения первой волны проблем забывает о её существовании, берет самоотвод, переложив заботы на технических специалистов, до того момента, пока критическая точка недовольства системой пользователями не достигнет локального максимума. И, если руководство заинтересовано в том, чтобы система продолжала функционировать, то прикладываются усилия для того, чтобы локальный всплеск недовольства постепенно не перерос в глобальный.
Применяя типичный консервативный славянский подход (ну никуда от этого не денешься :), хотя, возможно, я субъективен в своём размышлении) к решению проблем, руководство сразу после этого задумывается о том, что система нуждается в каком-то векторе развития. Наиболее популярные подходы к совершенствованию и сопровождению систем можно классифицировать следующим образом:
Все 4 подхода живут и здравствуют в различных типах компаний.
Пассивный подход
На данный момент, пожалуй, один из самых популярных подходов к «развитию» систем, но в этом плане, в последнее время, есть заметные положительные тектонические сдвиги в сторону более осмысленного использования ИС и применения лучших практик. Представляет собой залатывание существующих дыр в корпусе корабля, когда судно уже плывет. О проблеме задумываются только в тот момент, когда вода намочила ноги капитану, находящемуся на верхней палубе, при этом технический персонал, находящийся в нижних трюмах, уже порядком нахлебался морской водички.
Что интересно, в подобных проектах, в большинстве случаев, заказчик не заинтересован в том, чтобы найти системную причину проблемы. Собрали тебе корабль из гнилой древесины, при том пьяными руками плотников – значит судьба такая! Его удовлетворяет «временная» заплатка. Кстати, иногда, заплатка является источником новых проблем по той причине, что качественный модуль, внедренный в некачественный продукт, является источником новых «всплывающих» системных проблем. Всегда, когда работаешь над проектом, в голове надо держать цель, обеспеченную качеством, при этом стоит помнить, что качество – это свойство продукта, удовлетворяющее заказчика. Более качественный продукт просто не нужен. Это как пытаться поставить мотор от мерседеса на опель. Да поедет, да звук будет бешеный, но платформа не потянет таких преобразований и то, что как-то работало, перестанет работать совсем.
Таким образом, рассматриваемый тип подхода можно охарактеризовать как проект, который развивают (вообще этот глагол к данному типу подхода сложно применим) по остаточному принципу, если «будет свободный ресурс». А у Вас он когда-то бывает?
Активный подход
Активный подход отличается от предыдущего только более высокой и оперативной степенью реагирования на возникающие задачи и проблемы. Тут нет качественного перехода между подходами, нет перехода на другой уровень осознанности и зрелости организации работы, а наблюдается только количественные изменения и преобразования. Безусловно, этот подход более ответственен и профессионален, чем пассивный, но при этом все изменения касаются только «внешних» сторон проекта. Системные проблемы всё еще не решаются, но при этом есть вероятность того, что корабль (пусть даже сильно потрепанный) доплывет до пункта назначения за счет энтузиастов, которые в трюме корабля ложками вычерпывают воду. Этот подход, как правило, применяется в том случае, когда у заказчика есть заинтересованность в развитии, но при этом это больше «внешнее» желание, которое продиктовано не сознательной необходимостью в развитии, а желанием хорошо отчитаться за проделанную работу (пусть даже перед самим собой). Этот тип подхода отличается от предыдущего типом специалистов. Здесь они более сознательные и ответственные за то дело, которые делают, но, как правило, не опытные и молодые (но ничего, этот недостаток быстро проходит).
При таком типе развития нет необходимости в специфических инструментах, которые необходимы специалистам в работе. Все решения о развитии принимаются либо на интуитивном уровне, либо после непродолжительного сбора информации о возникающих проблемах, либо желаний автоматизации того или иного недостатка в ПО.
Проактивный подход
Если первые два подхода отличались друг от друга количественными оценками работы, то данный подход является самым качественным, продуманным, осмысленным и дико ресурсозатратным. Порой супер ресурсозатратным. Если тип подхода «пассивный» наиболее распространен на практике, то рассматриваемый тип подхода наиболее распространен в теоритической литературе, описывающей процесс организации сервисной работы в части сбора требований.
Это не просто подход к развитию задач, а принцип жизни консультанта, который должен предугадывать желания пользователей по движению глаз, угадывать их мысли и быть сравни IT Нострадамусу, который предвидит будущее.
Вышеупомянутую методологию ТРИЗ можно отнести именно к этому подходу. В подобных типах подходов к развитию ИС нам в принципе не обязательно общаться с пользователями, мы можем заранее спрогнозировать то, что им понадобится в будущем, но это не всегда работает, особенно если учитывать психологию людей. На определенных этапах работы с пользователями у них появляется ощущение того, что все изменения, какие-бы великолепные они не были, им навязывают. После чего появляется психологический блок, и решение задач заходит в тупик. Ключевые пользователи относятся к ИС как к своей младшей дочери и тоже эпизодически хотят влиять на её рост и развитие, поэтому так необходимо общение с пользователями при каждой доработке, даже если Вам уже очевидно, что и как делать дальше. Существует риск нарваться на слова пользователей: «А мы не ИМЕННО такое хотели!».
При решении задачи с помощью активного подхода, задача будет оперативно решена и на этом жизненный цикл работы с ней закончится. При решении задачи проактивным подходом, проблема будет системно решена, после чего тренд решения должен быть развит, и сопоставлен с объективными внешними и внутренними обстоятельствами окружения задачи. На выходе мы получим не просто решение, а стратегическую локальную карту развития. Безусловно, звучит очень заманчиво, но:
Только этого списка достаточно для того, чтобы понять, что если нет заказа с четкими требованиями и четким пониманием цели, то объективный прогноз составить затруднительно, и все усилия будут тщетными.
При работе в таком типе подхода к развитию ИС слишком много «слишком». Он слишком прогностический для работы с пользователями, слишком ресурсозатратный (чего только стоит обосновать заказчику, что ему понадобится именно такое решение), слишком умный (а этого, пожалуй, заказчики не могут простить, прежде всего).
Предпроактивный подход
Наиболее оптимальный подход с точки зрения прогнозирования потребностей пользователей на недалекую перспективу и затрат рабочих ресурсов на этот процесс.
Пользователь должен сам созреть и осознать необходимость изменения. Навязывать ему что-то, пусть даже объективно более совершенное глупо и не дальновидно. Он этого:
Порой слишком перспективный взгляд вперед остается непонятым и недооцененным. Большинство мыслит категориями сегодняшних обязанностей и не стремится заглядывать далеко вперед. Аналитик должен быть подобен хорошему шахматисту, который в состоянии просчитать несколько шагов вперед, но при этом быть в состоянии их изменить в зависимости от того, как будет вести себя соперник. Пожалуй, лучше всего это охарактеризуется определениями «тактик и стратег». У Вас есть маленький сын, учащийся в 3 классе, который постоянно мучает Вас вопросами по математике. И Вы уже подсознательно ощущаете, что растет будущий талант именно в этой области. Вы, как заботливый отец, не вручите ему сразу талмуд по тригонометрии, добавив к нему методичку по алгебре для поступающих на мехмат. А почему? Потому что, как имеющий опыт мыслящий взрослый, Вы прекрасно понимаете, что до этих знаний он должен дорасти и быть к ним готовым. Именно поэтому Вы отправите свое чадо к заботливому репетитору, который будет пестовать и развивать Вашего ребенка. При этом Вами не может быть не учтен тот факт, что за 7 лет, которые остались до поступления в ВУЗ, взгляды и предпочтения юного математика могут кардинально измениться. Вот так же стоит подходить и к заказчикам. Они те же самые «дети» в той области, где Вы уже подросток :).
Предпроактивный подход к развитию системы является «золотой серединой». Это уже далеко не пассивный подход к «залатыванию дыр по горячим следам», но еще и не провидческий подход, требующий стратегического видения рассматриваемой задачи. Сочетая в себе черты как второго, так и четвертого по нашей классификации, этот подход позволит в любой момент, не затрачивая дополнительного ресурса, изменить способ развития системы (причины могут быть разными, начиная от дополнительного финансирования и увеличения роли ИТ в компании и заканчивая полисным сценарием с урезанием бюджета).
Об анализе информации
Отдельного упоминания заслуживает технология сбора рабочей информации и её последующий анализ. Обсуждать конкретные инструменты и вендоров не вижу смысла, так как для составления объективной и целостной картины необходимо выполнить аналитическое исследование, а я себе такой задачи не ставил, да и каждый из нас в этой теме ориентируется довольно хорошо (а если я заблуждаюсь, то да прибудет с Вами «Поиск» 🙂 ). Остановлюсь на содержательной части сбора и работы с данными.
Проанализировав деятельность специалистов и инструментарий, который они задействуют в работе, можно с высокой долей вероятности определить тот тип подхода, который проповедуется в конкретной организации. Причем под специалистами понимаются не только аналитики, но и все, кто прямым или косвенным образом связан со сбором, классификацией, систематизацией требований, запросов и т.д. поступающих от пользователей ИС. Здесь, прежде всего, я веду речь о сотрудниках службы поддержки («Help desk») или тех сотрудниках в организации, которые выполняют эти обязанности.
Вообще это отдельная большая и содержательная статья о гармоничном и эффективном взаимодействии специалистов внутри проектной команды для получения качественного результата и достижения проектных целей. На мой взгляд, первый и лучший «собрат» аналитика это именно сотрудник службы сопровождения, которому поступают первичные запросы/вопросы о работоспособности нашего ПО. Любой запрос, относящийся к нашей ИС, должен быть однозначно классифицирован, а для этого сотрудник поддержки должен хоть немного (а хотелось бы, чтобы это было «много») ориентироваться в функциональности ИС на пользовательском уровне. Идеально, чтобы часть функциональных обязанностей нашего comrade была завязана на использовании рассматриваемой ИС в работе. Это будет способствовать тому, что он сам станет генератором грамотных идей для совершенствования нашей ИС. Да, на первый взгляд звучит довольно бредово, но создать определенную, хоть и малозначительную рабочую роль в системе, пусть даже и пользователю другой организации (если наш сценарий аутсорсинг), вполне реально, а если к этому процессу еще и привлечь заказчика, грамотно завуалировав для него эту просьбу с помощью следующего посыла: «Неужели лишние рабочие руки Вам повредят?», то Вы обречены на успех. А если это будет сам сотрудник заказчика, то тут уж все карты Вам в руки.
Любой запрос должен быть однозначно классифицирован и верно соотнесен с функциональностью нашего ПО. Это жизненно важно для выявления системных взаимосвязей возникающих проблем. Обычно пользователи просто говорят нам о том, что именно им неудобно, не задумываясь над тем, откуда берутся истоки этого неудобства. Наша задача заключается как раз в том, чтобы понять истоки, трассировать путь их появления и исправить все в корне (может и проблемы то нет, а пользователю просто необходимо уделить толику внимания и показать ему, как работать правильно). После того, как истоки выявлены, очень важно собрать статистику по работе с запросами. Статистика должна быть как можно более детальной и многоаспектной: время работы с запросами, количество запросов по конкретному пункту классификации, преобладающее количество запросов после веховых событий в проекте (установка обновления, выполненные процедуры с рабочей БД) и т.д. Не хочу быть банальным, но в данном случае есть только один совет – «Бездарное произведение отличается от гениального только количеством проработанных деталей» (с). Собранная статистика нуждается в постоянной проработке и анализе. Что является поводом для процедуры анализа определяете Вы сами – интервал времени, количество запросов (каждые 100, 500 новых). Все зависит от типа управления Вашим проектом и личных пожеланий руководства или возникающей необходимости. Лучше всего, если у Вас будет автоматизированный (а еще лучше если автоматический) инструмент для обработки значений собранной статистики и её наглядного представления. В этом есть еще одно заманчивое преимущество – Результаты анализа послужат необходимым основание для разработки того или иного требования или пересмотра ранее установленных приоритетов по уже существующим задачам. Это тоже одно из направлений работы аналитика – безапелляционно убедить контрагента принять новую/изменившуюся позицию. Если это не удается, то подтолкнуть к принятию, если и это не удается, то зародить сомнение в эффективности существующей идеи/модели, если и это не удается, то не отчаиваться, а искать пути решения.