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

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

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

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

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

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

Как целесообразно и грамотно действовать в этой ситуации? У кого какие предложения и рекомендации, личные мылси или возможно личный опыт?

Эд, слова "новый продукт с отсутствующими ЗЛ" и "типовое решение" противоречат друг другу.

Эд, слова "новый продукт с отсутствующими ЗЛ" и "типовое решение" противоречат друг другу.

Ден мне сложно сформулировать не говоря конкретно.

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

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

Идеи не рождаются на пустом месте. Если компания понимает, что может сделать "хорошее решение", значит, по крайней мере, известна проблема, которую нужно решить. Возможные варианты:
1) у компании есть опыт предоставления услуг в этой сфере;
2) знакомый врач за кружкой пива пожаловался, что без автоматизации он как без рук, и обозначил на салфетке проблему;
3) во время визита аналатика в местную поликлинику и ожидания в многочасовой очереди в его голове начали роиться мысли, как можно улучшить обслуживание с помощью информационной системы.

Варианты развития:
1) а значит, есть и некоторое представление о предметной области и более-менее налаженные контакты получения информации о процессах;
2) этот знакомый врач и является "проводником" к процессам - сначала нужно выудить как можно больше информации из него лично, и через него же попробовать выявить других заинтересованных лиц и наладить с ними контакты;
3) возможно, у ИС нет заинтересованных лиц, кроме томящихся в очереди граждан. А они вряд ли выступят спонсорами проекта.


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

Спасибо за ответ,

Идеи не рождаются на пустом месте. Если компания понимает, что может сделать "хорошее решение", значит, по крайней мере, известна проблема, которую нужно решить. Возможные варианты:
1) у компании есть опыт предоставления услуг в этой сфере;

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

2) знакомый врач за кружкой пива пожаловался, что без автоматизации он как без рук, и обозначил на салфетке проблему;

Жалоб таких нет, но понимание того, что автоматизации все-таки скорее благо, чем нет - существует...

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

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

Варианты развития:
1) а значит, есть и некоторое представление о предметной области и более-менее налаженные контакты получения информации о процессах;

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

2) этот знакомый врач и является "проводником" к процессам - сначала нужно выудить как можно больше информации из него лично, и через него же попробовать выявить других заинтересованных лиц и наладить с ними контакты;

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

3) возможно, у ИС нет заинтересованных лиц, кроме томящихся в очереди граждан. А они вряд ли выступят спонсорами проекта.

Это понятно, в этом смысле трудно полагаться на их поддержку ...

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

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

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

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

Предложение:
Если нет достаточно отчетливой (для проектирования ИС) цели и даже проблем на, так сказать, бизнес-уровне (предметной области Заказчика) то требуется выполнить работу бизнес-аналитика. На первом этапе - попытаться вывести Заказчика на формулирование его проблем (в его предметной области) в достаточно отчетливой (для проектрования ИС) форме.
Идеально, если он сам выговорит приемлемые формулировки, а не кивнет Вам в знак согласия. Это все бывает достаточно мучительно (для обоих сторон:)), но если четкое понимание болезней (проблем или целей) отсутствует то, чтобы лечить пациента, эти процедуры неизбежны. Менее болезненная, но возможно, более затратная  альтернатива пригласить стороннего опытного доктора-эксперта (не в вопросах собственно лечения, а менеджмента процессов).

Чтобы интервью привело к желаемым для Вас результатам, необходимым, но не достаточным условием является наличие у вас рамочных представлений о предметной области. Необходимо направлять интервью так, чтобы не выходить за эти рамки. Эти рамки на обсуждение могут быть наложены в виде схем (фактически, простейших референтных моделей, которые доступны уже Вам, даже если Вы врачом не являетесь). Предлагаю исходить из того, что в данной ситуации, Вы сами можете формулировать суждения о предметной области Заказчика в общем виде, но с признаваемой обеими стронами достоверностью.
Интервью - естественно, на основе заготовленных вопросов (анкеты). Но анкета обычно задает очень сильные рамки и неявно основана на некоторой референтной модели предметной области. Если модель в основе - слишком общая, а Заказчик инициативен и говорлив - возможна "потеря управления" (Вами) в ходе интервью. Если слишком жесткая (конкретная), то в неё "не ляжет" обсуждаемая проблематика и она неявно в ходе обсуждения будет отложена в сторону. Удобно представить предлагаемые референтые модели в виде схем. Они легче адаптируются (перерисовываются) в ходе разговора. Поскольку обсуждение ведется всё-таки словами, они, конечно, не заменяют, а дополняют анкету. Не уверен, что все необходимые для обсуждения бизнес-области схемы по теме "цели-проблемы" удастся упаковать сразу в стандартные нотации

Предлагаемая цель обследования, которое Вам необходимо провести: "Выявление целей и проблем Заказчика".
1. Предлагаете Заказчику сформулировать проблемы
2. Сформулированные проблемы подразумевают, что они возникают в ходе деятельности Заказчика. Предложите Заказчику уточнить, при достижении каких целей у него эти проблемы возникли. Попробуйте выяснить историю их возникновения.
3. Дальше самое интересное - заявленные цели могут с Вашей точки зрения не соответствовать заявленным проблемам. Обсуждение этой неувязки может заставить пересмотреть список проблем и целей и связи между ними. Важно держать фокус на деятельности именно Заказчика, при попытке обсуждать профессиональные проблемы в широком смысле фиксировать их, но аккуратно возвращать собеседника к тому, как они связаны с конкретной деятельностью (процессами) его организации.
4. В принципе, переключение между целями и проблемами может происходить бесконечно долго, важно, чтобы в ходе обсуждения происходила "фокусировка", конкретизация, сужение, уточнение рамок до достижения "разрешающей способности" (или исчерпания терпения сторон.

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

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

Ребята,

Вы не путайте маркетинговую часть и анализ.
Ну например это инвестиционный проект, Заказчика как такого нет. Цели и проблемы были сформулированы в ходе опроса знакомого врача (ей).

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

Как выявлять требования в этом случае?? Как удостовериться что все необходимые требования собраны, если нет как таковой заинтересованности потенциальных Заказчиков?

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

Хорошим аргументом для первого заказчика может быть ТЭО с обоснованием внедрения.

Именно на этом пока все и построено. То есть техникоэкономическое обоснование решения, правда несколько замаскированное под отчет об обследовании.

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

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

Другое дело - это убеждение в необходимости внедрения. Ты все правильно сказал.

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

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

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

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

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

Идеально, если он сам выговорит приемлемые формулировки, а не кивнет Вам в знак согласия.

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

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

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

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

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

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

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

Очень хорошая рекомендация

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

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

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

Нельзя ли это прокомментировать некоторыми ассоциативными примерами?

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

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

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

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

С какой целью ты склоняешь его к комплексному обследованию, когда оно ему не нужно?

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

Допустим, заказчик адекватен, вот и решай его проблемы, зачем тебе что-то еще?

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

Тебе не нужна картина в целом, ты предлагаешь решение конкретных проблем.

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

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

Вряд ли формулировка проблемы в таком общем виде может дать конструктивную рамку для проектирования системы: если система, решающая такую общую проблему, могла бы быть создана, она решила бы проблемы в любой области деятельности. Поэтому она должна была бы обладать универсальностью карманного калькулятора при такой же ограниченности функционала.
Специфика контроля ВСЕГДА связана с предметной спецификой деятельности и УНИВЕРСАЛЬНЫХ решений контроля для любых видов деятельности не существует. Можно обсуждать требуемый УРОВЕНЬ ОБЩНОСТИ описания этой специфики, но без специфики предметной области (фактически - референтной модели) обойтись невозможно.

Примеры вопросов:
Какие именно поручения? Не могли бы Вы привести перечень поручений, которые необходимо контролировать?
В этом месте при попытке уточнить содержание выполняемых поручений Вы выходите на обсуждение деятельности Заказчика в широком смысле:
* зачем вообще нужно выполнять эти поручение - переход к обсуждению основных целей и процессов организации
* есть ли условия при которых это поручение должно быть выполнено
* насколько точно можно вообще установить (проверить) факт выполнения поручения, в чем заключается (измеряется) результат
* улучшит ли автоматизация контроль? Нельзя ли привести примеры конкретных ситуаций, когда исполнение поручений не было проконтролировано? Кем? Почему?
 
1. Действительно ли этот человек не выполнил контрольные действия, потому что в его распоряжении не было удобных (автоматизированных) средств? Отсюда вопрос - почему Заказчик вообще уверен, что автоматизация контроля решит задачу контроля как таковую? Например, если суть контрольных действий будет сводиться к вводу исполнителем и/или проверяющим необходимой информации, то не будут ли эти действия для пользователей системы обременительными? Особенно, если для пользователей ввод контрольной информации никак не облегчает выполнение их работы, а является дополнительной нагрузкой. В этой ситуации саботаж использования контролирующей системы весьма вероятен... Это так же иллюстрирует проблему возможного несоответствия заявленных проблем/целей и предполагаемых решений. Уточняя, конкретизируя проблему и уточняя, конкретизируя решения Вы получаете более отчетливую ("сфокусированную") картину

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

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

Спасибо, Shur. Интересный комментарий и дельные советы.

Могу добавить, что год назад уже возникала потребность в системе документооборота и отслеживании выполнения поручений. Все началось с того, что было поручено просмотреть ряд сущестующих решения: Ефрат, 1С:Архив, PayDox.
Однако сразу стало ясно, что нет измереямых критериев для выбора, так как не понятно зачем они, эти системы вообще нужны. И какую цену готов платить Заказчик.

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

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

Пока работа по контролю исполнения поручений (т.е. обследование проблемы) не проводилось, оно так сказать впереди. Ваши комментарии очень кстати.