Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Боюсь, что Юрий такой же вопрошающий.
повторю.
Задачи:
- анализ потребностей рынка,
- анализ продаж,
- анализ эффективности работы персонала,
- анализ эффективности принятых решений и анализ эффективности решений, еще не принятых.
График:
начало - 21 ноября
сбор требований - 4 дня - 24 ноября
анализ источников 1 день - 25 ноября
Юниверсы - 6 дней - 5 декабря
Отчеты и дэшборды - 10 дней - 19 декабря
тренинг - 3 дня - 22 декабря
Физически делаем 20 отчетов, связанных с решением задач. Количество пользователей 10.
Источники данных:
1. База MySQL,
2. Excel (предполагалось SalesForce.com)
Да и интеграция с SAP - достаточно веский аргумент в пользу BO. Просто очень
интересует вопрос про функциональность. Что ты получаешь на выходе и за какие деньги.
А то SAP - все сразу и дорого. А что ты будешь использовать из всего полученного,
не всегда понятно.
Стоит отметить, что ни одна японская автомобильная компания не использует продукты SAP для автоматизации управления производством (ни планирование, ни управление движением в цехах). Поэтому было совершенно странно рассматривать "стандартное" решение SAP Automative для заводы Magna, который использует Kanban, или предлагать менеджменту автоматизацию с помощью функционала "ручного" перемещения запасов.
Юрий, правильно ли я понимаю, что scope проекта предполагается возможно менять в течение проекта в зависимости от сложности внедрения того или иного участка? Не могли бы вы тогда схематично описать рамки данного проекта, какие результаты предполагаются на выходе и что было вынесено для дальнейшего внедрения? Я допускаю, что я пропустил эту информацию, но хотелось бы большей конкретики. И еще один вопрос, который я задавал ранее относительно источников данных для BO. Какие источники используются сейчас и как организована передача данных? Спасибо.
Павел,
Данный проект, на мой взгляд, изначально задумывался как гарантированно успешный, поскольку проектная группа в ходе проекта может выбирать, что будет делать в течение 30 дней, а что стоит вынести за рамки проекта и отложить на будущее.
У Вас будет использоваться такой же подход, или Вы до начала проекта определитесь с Вашими требованиями к планированию/бюджетированию и аналитике/отчетности? И на какой платформе Вы планируете внедрять SAP BPC (MS или NW)?
Чуть выше говорилось об этом. Все равно ждем SP2, т.к. имеем богатый опыт и не хотим быть "подопытными кроликами"... Про конкретные проблемы не знаю, но знаю, что они есть.
Судя по рекламе и докам в BO 4.0 много всего хорошего и интересного заявлено:-)
Да и SP1 уже вышел, всеравно ждем SP2? Не в курсе какие еще проблемы остались нерешенными там?
Павел,
Данный проект, на мой взгляд, изначально задумывался как гарантированно успешный, поскольку проектная группа в ходе проекта может выбирать, что будет делать в течение 30 дней, а что стоит вынести за рамки проекта и отложить на будущее.
У Вас будет использоваться такой же подход, или Вы до начала проекта определитесь с Вашими требованиями к планированию/бюджетированию и аналитике/отчетности? И на какой платформе Вы планируете внедрять SAP BPC (MS или NW)?
Мы не выбрали 4.0 из-за того что продукт не доработан и аппаратные требования у него большие.
Молодцы! Доложились за прошедшую неделю :-) Почему все-таки не выбрали BO 4.0 не ответили :-)-
Прошла еще неделя, пора бы уже доложиться о состоянии дел на проекте? :-)
Все упирается в историю развития систем. Сначала была одна система и там кто-то как-то что-то вводил, потом возникла другая система, в которой тоже другой кто-то что-то как-то вводил.
Потом появилась идея объединить эти источники на уровне отчетности. Нарисовали процедуру обмена id-шниками, т.е. в каждой системе есть поля объединения с другой системой. Вопрос в другом - некоторые поставщики BI систем предоставляют драйвер к SalesForce, а некоторые хотят на этом строить бизнес. Тип владения тут ни при чем.
Было бы интересно услышать примеры производительности SAP BP - например, такой-то отчет, используемый для решения такой-то задачи, для него столько-то записей закачивается в микрокуб за столько то времени, потом столько-то времени строится отчет. Потом на актуализацию микрокуба уходит еще столько-то времени, и т.п.
Спасибо Филипп. Очень интересно. А можно поподробнее про "маппить" коды принятые в CRM.
Почему нельзя было принять единый классификатор для всех систем сразу. Или это связано с
типом владения ( как я понял - аренда).
В настоящее время все больше предприятий начинают внедрять у себя процедуры по управлению рисками (процедуры риск-менеджмента), в то же время полагая, что данные процедуры являются не более, чем новомодным введением, пришедшим к нам с запада, но имеющим низкое влияние на реальную ситуацию в российских компании. В рамках данного обзора я хотел бы сделать небольшой исторический экскурс в теорию риск-менеджмента и описать реальные причины внедрения данных процедур на предприятии.
Риск-менеджмент (управление рисками) — процесс принятия и выполнения управленческих решений, направленных на снижение вероятности возникновения неблагоприятного результата и минимизацию возможных потерь, вызванных его реализацией.
Теория риск-менеджмента основывается на трех базовых понятиях: полезности, регрессии и диверсификации.
Базовыми методами риск-менеджмента являются отказ от риска, снижение/ смягчение, передача/изменение и принятие.
Наиболее часто применяемым инструментом риск-менеджмента является страхование. Страхование предполагает передачу ответственности за возмещение предполагаемого ущерба сторонней организации (страховой компании). Примерами других инструментов могут быть отказ от чрезмерно рисковой деятельности (метод отказа), профилактика или диверсификация (метод снижения /смягчения), аутсорсинг затратных рисковых функций (метод передачи/ изменение), формирование резервов или запасов (метод принятия).
Процесс управления рисками является двухэтапным процессом:
Этап 1 - Анализ риска
Этап 2 - Управление риском
На первом этапе происходит выявление риска с сопутствующей оценкой вероятности его реализации и масштаба последствий; осуществляется разработка риск-стратегии с целью снижения вероятности реализации риска и минимизации возможных негативных последствий;
На втором этапе выбираются методы и инструменты управления выявленным риском; производится непосредственное управление риском; оцениваются достигнутые результаты и корректируется риск-стратегия.
Ключевым этапом риск-менеджмента считается этап выбора методов и инструментов управления риском.
Риск можно измерять по двум основным показателям:
На основе этих двух величин можно рассчитать интегральный показатель риска, который будет равен произведению величины прогнозируемого ущерба на вероятность наступления неблагоприятного события:
Риск = Ущерб × Вероятность.
Одним из ярких примеров применения положений риск-менеджмента в реальной экономике является требования по исполнению положения Sarbanes-Oxley (SOX).
Sarbanes-Oxley (SOX) Act of 2002 известный как Закон Сарбейнса-Оксли – законодательный акт, который определяет требования к финансовому менеджменту в корпорациях, ценные бумаги которых котируются на фондовой бирже США.
Sarbanes-Oxley Act от 2002 года был принят после ряда корпоративных скандалов (прежде всего дело Enron, WorldCom) и направлен на защиту прав инвесторов. С июля 2005 года закон Sarbanes-Oxley (SOX) применяется ко всем (в том числе и неамериканским) компаниям, чьи акции представлены на американском фондовом рынке. Сегодня соответствие Sarbanes-Oxley стало общемировой практикой бизнеса и многие компании добровольно приняли требования SOX для повышения инвестиционной привлекательности и возможности ведения бизнеса на международном рынке.
Sarbanes-Oxley (SOX)- это новый способ, позволяющий предупреждать риски. Он налагает ряд серьезных требований к процедурам внутреннего контроля, организации бизнес-процессов, в т.ч. к ведению управленческого учета и бюджетирования. SOX относится к законодательству, направленному на регламентацию работы финансовых служб, прозрачность банковских операций и независимость контролеров. Исполнение требований по SoD является одним из базовых положений SOX.
Особого внимания заслуживает следующее положение закона Sarbanes-Oxley (SOX):
Раздел 404Этот раздел требует от всех АО (открытых акционерных обществ) включать «внутренние» отчеты в свою ежегодную отчетность. Подобная система утверждает ответственность руководства за выполнение процедур внутреннего контроля. Правила также включают в себя оценку эффективности процедур внутреннего контроля со стороны руководства компании. В то же время, подразделения, осуществляющие внутренний контроль, должны включать в ежегодный отчет компании собственную оценку работы руководства в соответствии с принятыми стандартами.
Данный раздел является самым сложным в применении, так как большинство АО управляли своими финансовыми потоками без использования детальной отчетности. Компании должны вводить системы внутреннего контроля, оценивать их уязвимость, определять пути проверки их эффективности.
30 июля 2002 г. Президент Буш подписал Закон Сарбанеса-Оксли (англ. Sarbanes-Oxley Act), который представляет собой одно из самых значительных событий по изменению федерального законодательства США по ценным бумагам за последние 60 лет. Значительно ужесточает требования к финансовой отчётности и к процессу её подготовки — результат многочисленных корпоративных скандалов, связанных с недобросовестными менеджерами крупных корпораций.
В соответствии с Законом, для публичных компаний:
Закон, получивший название от имен создателй — сенатора Пола Сарбанеса (демократическая партия, шт. Мэрилэнд) и члена палаты представителей Майкла Оксли (республиканская партия, шт. Огайо) — состоит из 11 разделов. Рассматриваются вопросы независимости аудиторов, корпоративной ответственности, полной финансовой прозрачности, конфликта интересов, корпоративной финансовой отчетности и др.
Раздел I. Совет по контролю за аудитом и отчетностью публичных компаний
Раздел II. Независимость аудитора
Раздел III. Ответственность компаний
Раздел IV. Дополнительные требования к раскрытию финансовой информации
Раздел V. Конфликт интересов аналитиков
Раздел VI. Ресурсы и полномочия Комиссии по ценным бумагам и биржам
Раздел VII. Исследования и отчеты
Раздел VIII. Уголовная ответственность за мошенничество
Раздел IX. Ужесточение наказаний за преступления должностных лиц
Раздел X. Налоговые декларации компаний
Раздел XI. Корпоративное мошенничество и ответственность
Как видно из приведенных мной выше примеров, разработка эффективной системы контроля снижения рисков на предприятии является реальным требованием экономики и хорошим стимулом, обеспечивающим повышение эффективности деятельности любого коммерческого предприятия.
SAP и Business Objects выпустили масштабное обновление семейства совместных продуктов в области управления эффективностью бизнеса (enterprise performance management, EPM). Ключевой особенностью нового решения, по заявлению разработчика, является тесная интеграция между решениями в области стратегического управления, бизнес-анализа и управления рисками (governance, risk and compliance, GRC), основанная на использовании технологических платформ SAP NetWeaver и Microsoft. Наличие значительного количества новых продуктов, их версий и вариантов их технологических реализаций, на мой взгляд, существенно расширяет возможности автоматизации различных бизнес-процессов компании, но при этом существенно осложняет процесс построения оптимальной архитектуры решения. В этой связи рассмотрение вопросов связанных с описанием процесса развития продуктов SAP BPC для различных технологических платформ является крайне актуальным.
С прикладной точки зрения использование SAP BusinessObjects Planning and Consolidation позволит получить для предприятия следующие преимущества:
Также SAP BusinessObjects Planning and Consolidation осуществляет поддержку сервисно-ориентированной архитектуры (SOA), предусматривает возможность интеграции данных из различных учетных систем (SAP, плоские файлы, сторонние системы), предусматривает возможность использования всего стандартного функционала MS Excel, позволяет испольовать Web-интерфейс, определяет четкую последовательность действий конечного пользователя , предоставляет возможность ускоренной разработки дополнений и расширения приложений.
Работа с информационной системой на основе SAP BPC может быть построена следующим образом: Руководством сверху ставится задача, устанавливаются сроки и предоставляютя инструкции по ее исполнению. При этом обеспечивается совместная работа и обмен информацией между структурными подразделениями. Согласно поставленной задаче, осуществляется внесение плановых данных сотрудниками в централизованную систему в соответствии с корпоративной методикой планирования. На основе собранных данных происходит консолидация с учетом предварительного анализа , а также моделирование различных сценариев развитя деятельности предприятия. В дальнейшем формируется отчетность и осуществляется анализ представленных данных.
В соответствии с информационной моделью компании и с метолологией бюджетирования разрабатывается хранилище, где будут храниться данные с разной степенью детализации, что позволяет предоставить эти данные для руководства предприятия в масштабируемом виде.
На основе разработанного хранилища данных создаются формы планирования. Удобный интерфейс MS Excel оперирует достоверными и надежными данными из единой базы данных. Конечный пользователь имеет возможность сохранять комментарии в форме, использовать в форме расчетные функции Excel, осуществлять Off-line планирование, осуществлять переход от агрегированных форм к детальным и обратно, возможность добавлять новые строки. Инструментарий SAP BusinessObjects Planning and Consolidation предусматрвает возможность задавать последовательность действий конечного пользователя путем создания потоков бизнес-процессов с последующим отслеживанием статусов каждого этапа процесса.
SAP BusinessObjects Planning and Consolidation является надежным инструментом для планирования и консолидации, который способен выполнить любые задачи, связанные с бюджетированием, планированием, консолидацией или отчетностью, обладает функциями, необходимыми для распределения финансов и заданий в двух направлениях по иерархии предприятия, а также для консолидации, необходимой для своевременного и максимально успешного завершения финансового периода и при этом обладает неограниченной гибкостью при выборе оптимальной технологической платформы.
Автор совершенно правильно описывает вариант реализации исходящих платежей для того случая, когда сотрудники финансовой службы в некоторых российских компаниях хотят делать проводки по банку только на основании банковской выписки.
К сожалению, в этом случае (АПП без проводок) настройка выписки чуть усложняется. Большинство компаний (и на Западе и в Росиии) старается все-таки использовать АПП с проводками. Однако если требования бухгалтерии жесткое – делать проводки по факту, нужно задуматься о том, как удобнее сделать реализацию выравнивания платежей по факту.
Автор описывает в статье два механизма – ручное выравнивания через транзакцию F-44 и автоматическое, в момент загрузки и разбора банковской выписки. Для большого количества исходящих платежей ручное выравнивание, конечно же, не очень удобно. Я бы предложил отслеживать, чтобы банк возвращал номера исходящих платежных поручений в одном из полей выписки и делать выравнивание в момент загрузки выписки. Однако и в этом случае могут возникнуть также сложности. Дело в том, что при анализе выписки система может искать номер платежного поручения необычным алгоритмом. Сначала анализирует все встречающиеся числа, разделенные любым нецифровым символом и заносит такие во внутреннюю таблицу. А потом каждое число из этой внутренней таблицы подлежит проверке, не является ли оно номером необработанного платежного поручения. Если такое платежное поручение существет, то создается запись в таблице FEBCL «Клиринговые данные к отдельной позиции ЭлектрВыпискиИзСчета». Проблема возникает в том случае,когда в выписке встречаются разные другие числовые значения (например, специальные внутренние номера банка) и если эти значения случайно совпадают с номером существующей необработанной платежки. А этом случае система будет пытаться выравнить существующую позицию с этим платежным поручением. Естественно, неудачно. Это редкий случай но тем не менее, он может встретиться на практике.
SAP BusinessObjects Information Design Tool
02.12.2024Интеграция SAP решений со сторонними системами на основе SAP NetWeaver
03.12.2024Расширенная проверка доступности в SAP S/4HANA
03.12.2024Сравнение SAP ТОРО и 1С ТоиР
03.12.2024
Комментарий от
Сергей Шургин
| 15 декабря 2011, 14:53
Филипп Домитеев 14 декабря 2011, 17:58
Пользуясь случаем хочу спросить всех участников на счет советов по технической теме:
1. Есть ли у кого-то рецепты по формированию отчетов с наибольшем быстродейтсвием. В целом все работает быстро, но временами сделав отчет получаем паузу в минуты. Скорее всего просто не раскопали все.
2. Хотим синтегрроваться с SalesForce. Кто нибудь использует ODBC драйвер и где его взять ? Если нет как еще это можно сделать избежав выгрузок в Eхcel?
Хотя, конечно, интересно было бы узнать как работает SAP-овский интерфейс доступа к SalesForce.