Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
406
IMHO не надо ничей мозг шевелить, ведь люди, которых вы интервьюируете, идиотами не являются. при этом они гораздо лучше вас знают свой участок. вы просто научитесь слушать, понимать то, что вам говорят, направлять беседу, отделять главное от второстепенного.
Знание языка (русского-русского) и умение объяснить, что именно вам нужно, в этом сильно помогает.

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

дам еще один совет: чтобы научиться лучше работать, надо работать лучше :о))

Цитировать
для организации операционной и проектной деятельности своих ИТ подразделений и взаимодействия с подразделениями компании (не только через воронку службы Service Desk) необходимо разбираться и понимать бизнес компании.

это бесспорно

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

в общем, навыки ПМ надо прокачивать и брать на себя ответственность, либо отходить в сторону. как-то так...
надеюсь не в обиду.

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

и вообще нормальное управление проектами плохо живет в сочетании со студнеобразным управлением, которое похоже имеет место быть в вашем вузе. а студнеобразное управление проектами вообще нежизнеспособно.

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

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

IMHO Вам достаточно научиться задавать правильные вопросы, типа зачем/почему? а не что, как и куда?
например, зачем вообще существует это подразделение?
Также обратите внимание на то, что деятельность сотрудников в подразделении, а также самого подразделения (в лице его руководителя) ОЦЕНИВАЕТСЯ тем или иным образом. из сопоставления критериев оценки и фактических оценок довольно много становится понятно.

и не надо до поры до времени опускаться до уровня функций (а тем более операций) отдельных сотрудников. так Вы только время потеряете. опускаться нужно только тогда:
 - когда стоит такая задача
 - когда на предыдущем уровне процессов ВСЁ ЯСНО. (т.е. новая информация о них всегда укладывается в уже описанную картину).

это сродни подходу SADT.



409
IMHO мнение хорошее, даже, я бы сказал, интересное, но неправильное... уж извините

Цитата: AnGar
Процессы выявляются через связи 4 компонентов.
•   Организационной структуры.
•   Функциональной структуры.
•   Древа целей.

а четвертый где?

Цитировать
Первым шагом установим связь орг. структуры и функциональной структуры и получим организационно-функциональную матрицу, где на осях орг. единицы и функции, а в качестве связи роли, которые выполняются орг. единицами в рамках функции. На пример Руководит, Исполняет, Соисполняет, Использует результат/информацию.

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

Кстати, что Вы называете функциональной структурой? И зачем Вам эта матрица? С таким же успехом можно было бы взять положения о подразделениях и должностные инструкции (буде они существуют) - и вуаля! Вопрос только, ЧТО это дает исследователю?

Цитировать
Следующим шагом построим древо целей компании это, и определит нам набор процессов компании.

А вот цели - это как раз то, с чего надо начинать, именно они определяют, зачем всё это хозяйство нужно. Далее, раскручивая как обеспечивается достижение этих целей, и становится понятно как функционирует предприятие.

Цитировать
Далее для каждой цели определим последовательность функций реализующих цель.

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

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


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

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

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


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

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

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

411
возможно я раскрою Вам страшную тайну, но какую бы специальную ИС не поставить - посадить сколько-то бухов (какое всё-таки хорошее сочетание получилось :о))) за нее придётся. Т.к. сама ИС без участия человека пока работать не может.

Насчет грани между операциями и бизнес процессом - Вы неверно ставите вопрос, т.к. ее нет! Вообще! Любой БП в конечном счете состоит из операций, и в случае с бухучетом отдельные операции выполняют (составляют) учетную функцию для разных (причем иногда совершенно разных) бизнес процессов. Если говорить совсем просто: учетные функции (операции б/у) - часть бизнес процессов компании.
Возьмите для примера компанию, в которой Вы работаете, и "пройдите", например, по своей цепочке от первичной продажи до сдачи работ, отслеживая что, на каком этапе и как отражается в бухучете. Возможно после этого станет понятнее.


412
Цитата: Asd
Мне кажется, что, во-первых, слово "бизнес", как было верно замечено ранее, в данном контексте синонимично скорее слову "деловой", нежели "коммерческий".

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

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

Ну хорошо, пусть так...

Цитировать
Допустим, я готовлю отчёт для отдела А, отдел А - мой потребитель. Система менеджмента качества ИСО на этом и основана: она не гарантирует качество конечного продукта, но гарантирует, что внутри организации предпринимаются все возможные действия для обеспечения качества продукции.

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

Так что коллизия наблюдается в ваших рассуждениях.

Цитировать
Более того, ведение бухгалтерского учёта - это бизнес-процесс, ещё и потому, что он таки имеет интерфейсы с внешними потребителями организации. Даже в ФЗ "О бухгалтерском учёте" в разделе термины и определения закреплено понятие "потребитель бухгалтерской информации", и таких потребителей совсем не мало.

Еще раз - ведение бухгалтерского учета - НЕ ПРОЦЕСС! и совсем не потому, что "существуют интерфейсы". Бухгалтерский учет ведется для того, чтобы соответствовать требованиям в первую очередь государства в части оплаты установленным законодательством налогов. Для этого законодательно же устанавливается план счетов и ряд учетных правил. Но база для их начисления кроется в неких хозяйственных операциях, выраженных в денежной форме. не будет их, не будет возможности бухучета. Поэтому бухучет преимущественно состоит из ОПЕРАЦИЙ. Причем операции эти могут быть преимущественно связаны с хозяйственными операциями, по принципу: возьми из сведений, описывающих хозяйственную операцию, циферку и запиши ее в учетный регистр. Это если утрированно рассуждать.


413
пока одно замечание: культур много не бывает, обычно она (культура) одна - либо есть, либо нет :о)))

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

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

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

так что творческих вам успехов :о)))

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



417
вообще-то в ГОСТе написано следующее:
Проект ТЗ на АС разрабатывает организация-разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.).
При конкурсной организации работ варианты проекта ТЗ на АС рассматриваются заказчиком, который либо выбирает предпочтительный вариант, либо на основании сопоставительного анализа подготавливает с участием будущего разработчика АС окончательный вариант ТЗ на АС.



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

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

вот раздел 3 этого же отчета точно соответствует выполняемой работе - тут без вопросов.

по классификации процессов тоже перл: Все бизнес-процессы организации классифицируются на основные, обеспечивающие, развития, управления. В положении приводится полная классификация всех выделенных бизнес-процессов организации, разнесением их в 4 раздела.
1.   Основные бизнес-процессы.
2.   Обеспечивающие бизнес-процессы.
3.   Бизнес-процессы управления
4.   Бизнес-процессы развития.
Позвольте, но ведь этот документ называется методика. Т.е. в нем, видимо, должно быть написано, как это сделать? Но этого нет!

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

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

как-то так...


419
2 StUtk:
давайте начнем чуть ранее с вопроса: зачем вообще существует/организуется предприятие?
ответ вроде очевиден: в целях получения прибыли для своих учредителей.
следующий вопрос: а как предприятие будет получать прибыль?
ваша очередь отвечать...

420
нееее, не годится.
перечисленные пункты не имеют отношения к бизнес-процессам. ссылка IMHO не совсем в тему, а в аттаче много косяков, очень много.

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »