Меню

Сортировать:

Новое Популярное
Работаем на боевом юниверсе (39)

Комментарий от  

Сергей Шургин

  |  15 декабря 2011, 14:53

Филипп Домитеев 14 декабря 2011, 17:58

Пользуясь случаем хочу спросить всех участников на счет советов по технической теме:
 
1. Есть ли у кого-то рецепты по формированию отчетов с наибольшем быстродейтсвием.  В целом все работает быстро, но временами сделав отчет получаем паузу в минуты. Скорее всего просто не раскопали все.
 
2. Хотим синтегрроваться с SalesForce. Кто нибудь использует ODBC драйвер и где его взять ? Если нет как еще это можно сделать избежав выгрузок  в Eхcel?

Филипп, как бы не дешевле оказалось организовать витринку, где консолидировать данные из обеих систем. Выгрузки из SF позволят это сделать. "Бонусом" более удобная в работе физическая модель данных и вопроса быстродействия отдельных отчетов.
 
Хотя, конечно, интересно было бы узнать как работает SAP-овский интерфейс доступа к SalesForce.
Работаем на боевом юниверсе (39)

Комментарий от  

Павел Лифиц

  |  15 декабря 2011, 14:35

Евгений Литвиненко 14 декабря 2011, 16:11

Боюсь, что Юрий такой же вопрошающий.
повторю.
 
Задачи:
- анализ потребностей рынка,
- анализ продаж,
- анализ эффективности работы персонала,
- анализ эффективности принятых решений и анализ эффективности решений, еще не принятых.
График:
начало - 21 ноября
сбор требований - 4 дня - 24 ноября
анализ источников 1 день - 25 ноября
Юниверсы - 6 дней - 5 декабря
Отчеты и дэшборды - 10 дней - 19 декабря
тренинг - 3 дня - 22 декабря
 
Физически делаем 20 отчетов, связанных с решением задач. Количество пользователей 10.
 
Источники данных:
1.   База  MySQL,
2. Excel (предполагалось SalesForce.com)

Спасибо, Евгений, за ответ. Правильно ли я понял, что вы выступаете в роли Project Manager со стороны BigBuzzy? Планируете ли вы все-таки развивать полученную систему? Создание хранилища, например, входит в ваши будущие планы? Какие еще элементы системы вы планируете развивать на следующем этапе.
Просто, насколько я понимаю, это в некотором роде показательный рекламный проект и, в частности, финансовые условия данного проекта, видимо, специальные. В любом случае, я уверен, что результаты проекта будут крайне полезны для вашей компании. Другой вопрос, что проект как таковой не является законченным решением. Дальнейшая поддержка и развитие внедренных систем, процедур, отчетности и т.д. является необходимым элементом работы системы. Каковы ваши планы в этом направлении? Планируете ли вы поддерживать систему собственными силами или имеете какие-либо другие опции для этого?
Работаем на боевом юниверсе (39)

Комментарий от  

Филипп Домитеев

  |  14 декабря 2011, 17:58

Максим Селиверстов 12 декабря 2011, 16:47

Да и интеграция с SAP - достаточно веский аргумент в пользу BO. Просто очень
интересует вопрос про функциональность.  Что ты получаешь на выходе и за какие деньги.
А то SAP - все сразу и дорого. А что ты будешь использовать из всего полученного,
не всегда понятно.

Пользуясь случаем хочу спросить всех участников на счет советов по технической теме:
 
1. Есть ли у кого-то рецепты по формированию отчетов с наибольшем быстродейтсвием.  В целом все работает быстро, но временами сделав отчет получаем паузу в минуты. Скорее всего просто не раскопали все.
 
2. Хотим синтегрроваться с SalesForce. Кто нибудь использует ODBC драйвер и где его взять ? Если нет как еще это можно сделать избежав выгрузок  в Eхcel?
Опыт использования KANBAN в бизнес-процессе подготовки материалов для производства (3)

Комментарий от  

Владимир Закомирный

  |  14 декабря 2011, 17:43

Тимур Муратов 08 декабря 2011, 13:43

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

Очень жаль, но я откровенно не понял Вашего комментария. В тоне чувствую критику, но в содержании ее не улавливаю. Какая причинно-следственная связь между фактом, на который Вы обратили наше внимание  (автопром Японии не использует продукты SAP), и удивлением по поводу предложенных клиенту решений? Видимо, что-то есть между строк...
Я, например, теряюсь в догадках по-поводу того, что именно побудило автора статьи рассказать здесь об этом конкретном решении :), т.е. не могу правильно расставить акценты. Однако, отношу это на счет своей некомпетентности. Полагаю, для изучающих и внедряющих упомянутое индустриальное решение полезно узнать об альтернативном решении для подготовки материалов для производства (вместо ведомости подготовки материалов). Как, впрочем, и о том, что искать оптимальные решения - задача команды проекта...
Мне, например, было любопытно узнать о конкретном факте применения KANBAN (ярлык, япон.) - "старенькой" (1959) японской (TOYOTA) системы организации производства и снабжения, позволяющей реализовать все еще актуальный для России принцип JIT (2-е изд. книги Питеркина вышло в 2003 :))).
Работаем на боевом юниверсе (39)

Комментарий от  

Евгений Литвиненко

  |  14 декабря 2011, 16:11

Павел Лифиц 14 декабря 2011, 12:02

Юрий, правильно ли я понимаю, что scope проекта предполагается возможно менять в течение проекта в зависимости от сложности внедрения того или иного участка? Не могли бы вы тогда схематично описать рамки данного проекта, какие результаты предполагаются на выходе и что было вынесено для дальнейшего внедрения? Я допускаю, что я пропустил эту информацию, но хотелось бы большей конкретики. И еще один вопрос, который я задавал ранее относительно источников данных для BO. Какие источники используются сейчас и как организована передача данных? Спасибо.

Боюсь, что Юрий такой же вопрошающий.
повторю.
 
Задачи:
- анализ потребностей рынка,
- анализ продаж,
- анализ эффективности работы персонала,
- анализ эффективности принятых решений и анализ эффективности решений, еще не принятых.
График:
начало - 21 ноября
сбор требований - 4 дня - 24 ноября
анализ источников 1 день - 25 ноября
Юниверсы - 6 дней - 5 декабря
Отчеты и дэшборды - 10 дней - 19 декабря
тренинг - 3 дня - 22 декабря
 
Физически делаем 20 отчетов, связанных с решением задач. Количество пользователей 10.
 
Источники данных:
1.   База  MySQL,
2. Excel (предполагалось SalesForce.com)
Работаем на боевом юниверсе (39)

Комментарий от  

Павел Лифиц

  |  14 декабря 2011, 12:02

Юрий Марьинский 12 декабря 2011, 22:08

Павел,
Данный проект, на мой взгляд, изначально задумывался как гарантированно успешный, поскольку проектная группа в ходе проекта может выбирать, что будет делать в течение 30 дней, а что стоит вынести за рамки проекта и отложить на будущее.
У Вас будет использоваться такой же подход, или Вы до начала проекта определитесь с Вашими требованиями к планированию/бюджетированию и аналитике/отчетности? И на какой платформе Вы планируете внедрять SAP BPC (MS или NW)?

Юрий, правильно ли я понимаю, что scope проекта предполагается возможно менять в течение проекта в зависимости от сложности внедрения того или иного участка? Не могли бы вы тогда схематично описать рамки данного проекта, какие результаты предполагаются на выходе и что было вынесено для дальнейшего внедрения? Я допускаю, что я пропустил эту информацию, но хотелось бы большей конкретики. И еще один вопрос, который я задавал ранее относительно источников данных для BO. Какие источники используются сейчас и как организована передача данных? Спасибо.
Работаем на боевом юниверсе (39)

Комментарий от  

Завдат Ганиев

  |  14 декабря 2011, 11:32

Евгений Литвиненко 14 декабря 2011, 11:23

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

Ok, логично :-)
Работаем на боевом юниверсе (39)

Комментарий от  

Евгений Литвиненко

  |  14 декабря 2011, 11:23

Завдат Ганиев 14 декабря 2011, 11:18

Судя по рекламе и докам в BO 4.0 много всего хорошего и интересного заявлено:-)
Да и SP1 уже вышел, всеравно ждем SP2? Не в курсе какие еще проблемы остались нерешенными там?

Чуть выше говорилось об этом. Все равно ждем SP2, т.к. имеем богатый опыт и не хотим быть "подопытными кроликами"... Про конкретные проблемы не знаю, но знаю, что они есть.
Работаем на боевом юниверсе (39)

Комментарий от  

Евгений Литвиненко

  |  14 декабря 2011, 11:19

Юрий Марьинский 12 декабря 2011, 22:08

Павел,
Данный проект, на мой взгляд, изначально задумывался как гарантированно успешный, поскольку проектная группа в ходе проекта может выбирать, что будет делать в течение 30 дней, а что стоит вынести за рамки проекта и отложить на будущее.
У Вас будет использоваться такой же подход, или Вы до начала проекта определитесь с Вашими требованиями к планированию/бюджетированию и аналитике/отчетности? И на какой платформе Вы планируете внедрять SAP BPC (MS или NW)?

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

Комментарий от  

Завдат Ганиев

  |  14 декабря 2011, 11:18

Алексей Чуканцев 14 декабря 2011, 10:33

Мы не выбрали 4.0 из-за того что продукт не доработан и аппаратные требования у него большие.

Судя по рекламе и докам в BO 4.0 много всего хорошего и интересного заявлено:-)
Да и SP1 уже вышел, всеравно ждем SP2? Не в курсе какие еще проблемы остались нерешенными там?
Работаем на боевом юниверсе (39)

Комментарий от  

Алексей Чуканцев

  |  14 декабря 2011, 10:33

Завдат Ганиев 13 декабря 2011, 18:50

Молодцы! Доложились за прошедшую неделю :-) Почему все-таки не выбрали BO 4.0 не ответили :-)-

Мы не выбрали 4.0 из-за того что продукт не доработан и аппаратные требования у него большие.
Работаем на боевом юниверсе (39)

Комментарий от  

Завдат Ганиев

  |  13 декабря 2011, 18:50

Завдат Ганиев 13 декабря 2011, 10:20

Прошла еще неделя, пора бы уже доложиться о состоянии дел на проекте? :-)

Молодцы! Доложились за прошедшую неделю :-) Почему все-таки не выбрали BO 4.0 не ответили :-)-
Как работать с арендованными приложениями?! (4)

Комментарий от  

Завдат Ганиев

  |  13 декабря 2011, 18:46

Евгений Литвиненко 13 декабря 2011, 17:04

Все упирается в историю развития систем. Сначала была одна система и там кто-то как-то что-то вводил, потом возникла другая система, в которой тоже другой кто-то что-то как-то вводил.
Потом появилась идея объединить эти источники на уровне отчетности. Нарисовали процедуру обмена id-шниками, т.е. в каждой системе есть поля объединения с другой системой. Вопрос в другом - некоторые поставщики BI систем предоставляют драйвер к SalesForce, а некоторые хотят на этом строить бизнес. Тип владения тут ни при чем.

Да уж, SAP думаю мог бы с царского плеча дать возможность работать с SalesForce БЕСПЛАТНО, как с Oracle, думаю не Вы одни пользуетесь этим сервисом :-) Или это SalesForce должен прогнуться, чтоб пользователи BI  систем повернулись к ним лицом?:-)
 
В тексте упоминается, что Вы используете BO XI R3, но есть определенная путаница в маркировке версий BO, поэтому хочу уточнить- R3 - это Release 3?, т.е. по другому версия звучит как BO XI 3.x? Наверное 3.1, а не 3.0? С каким Service Pack? И вынужден заново задать свой вопрос: почему все-таки не используете навороченный BO 4.01? Только из-за того, что он новый и не до конца проверенный?
Работаем на боевом юниверсе (39)

Комментарий от  

Евгений Литвиненко

  |  13 декабря 2011, 17:16

Юрий Марьинский 12 декабря 2011, 22:15

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

Документ "Менеджеры. Все про **********" содержит 8 отчетов, которые показывают динамику продаж и выручки по менеджерам, регионам, разделам сайта, типам купонов, времени. Обработка ведется по всей базе (~ 1.5 - 2 млрд записей) и занимает максимум 90-100 секунд (время обработки запросов зависит от конкретной загрузки базы другими приложениями). Отчеты строятся мгновенно, т.к. вся обработка сохранена на сервере SAP BO. Сохраненный отчет в следующий раз открывается за милисекунды. Обновление данных необходимо проводить 1-2-3 раза в месяц.
Как работать с арендованными приложениями?! (4)

Комментарий от  

Евгений Литвиненко

  |  13 декабря 2011, 17:04

Максим Селиверстов 13 декабря 2011, 14:33

Спасибо Филипп. Очень интересно. А можно поподробнее про "маппить" коды принятые в CRM.
Почему нельзя было принять единый классификатор для всех систем сразу. Или это связано с
типом владения  ( как я понял  - аренда).

Все упирается в историю развития систем. Сначала была одна система и там кто-то как-то что-то вводил, потом возникла другая система, в которой тоже другой кто-то что-то как-то вводил.
Потом появилась идея объединить эти источники на уровне отчетности. Нарисовали процедуру обмена id-шниками, т.е. в каждой системе есть поля объединения с другой системой. Вопрос в другом - некоторые поставщики BI систем предоставляют драйвер к SalesForce, а некоторые хотят на этом строить бизнес. Тип владения тут ни при чем.
Как работать с арендованными приложениями?! (4)

Комментарий от  

Максим Селиверстов

  |  13 декабря 2011, 14:33

Спасибо Филипп. Очень интересно. А можно поподробнее про "маппить" коды принятые в CRM.
Почему нельзя было принять единый классификатор для всех систем сразу. Или это связано с
типом владения  ( как я понял  - аренда).
Работаем на боевом юниверсе (39)

Комментарий от  

Завдат Ганиев

  |  13 декабря 2011, 10:20

Прошла еще неделя, пора бы уже доложиться о состоянии дел на проекте? :-)
Разработка эффективной системы контроля снижения рисков (1)

Комментарий от  

Михаил Савкин

  |  13 декабря 2011, 05:48

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

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

Теория риск-менеджмента основывается на трех базовых понятиях: полезности, регрессии и диверсификации.

  • В 1738 году швейцарский математик Даниил Бернулли дополнил теорию вероятностей методом полезности или привлекательности того или иного исхода событий.
  • В конце XIX века английский исследователь Ф. Гальтон предложил считать регрессию или возврат к среднему значению универсальной статистической закономерностью.
  • В 1952 году аспирант Чикагского университета Гарри Марковиц в статье «Диверсификация вложений» («Portfolio Selection») математически обосновал стратегию диверсификации инвестиционного портфеля.

Цели и задачи риск менеджмента:

  • Избежание катастрофических потерь
  • Избежание главных неожиданностей или ошибок
  • Идентифицировать и понять факторы и события, которые могут влиять на достижение стратегических, деловых и проектных задач
  • Помогает получить альтернативное мышление о проектных действиях (новая перспектива)
  • Повышение конкурентоспособности хозяйствующих субъектов с помощью защиты от реализации чистых рисков
  • Гарантируемая возможность роста в бизнесе
  • Понимание разных видов риска
  • Анализы, предпринятые в риске-менеджменте, помогают определить проектные приоритеты
  • Риск-менеджмент предоставляет такое строение как — «где мы и как мы должны запланировать, чтобы достигнуть того, где мы хотим быть»

Как мы можем справиться с рисками?

  • Избежание рисков
  • Изменение рисков
  • Смягчение рисков
  • Принятие рисков

Базовыми методами риск-менеджмента являются отказ от риска, снижение/ смягчение, передача/изменение и принятие.

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

Этапы риск-менеджмента

Процесс управления рисками является двухэтапным процессом:

Этап 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

Этот раздел требует от всех АО (открытых акционерных обществ) включать «внутренние» отчеты в свою ежегодную отчетность. Подобная система утверждает ответственность руководства за выполнение процедур внутреннего контроля. Правила также включают в себя оценку эффективности процедур внутреннего контроля со стороны руководства компании. В то же время, подразделения, осуществляющие внутренний контроль, должны включать в ежегодный отчет компании собственную оценку работы руководства в соответствии с принятыми стандартами.

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

История SOX

30 июля 2002 г. Президент Буш подписал Закон Сарбанеса-Оксли (англ. Sarbanes-Oxley Act), который представляет собой одно из самых значительных событий по изменению федерального законодательства США по ценным бумагам за последние 60 лет. Значительно ужесточает требования к финансовой отчётности и к процессу её подготовки — результат многочисленных корпоративных скандалов, связанных с недобросовестными менеджерами крупных корпораций.

В соответствии с Законом, для публичных компаний:

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

Закон, получивший название от имен создателй — сенатора Пола Сарбанеса (демократическая партия, шт. Мэрилэнд) и члена палаты представителей Майкла Оксли (республиканская партия, шт. Огайо) — состоит из 11 разделов. Рассматриваются вопросы независимости аудиторов, корпоративной ответственности, полной финансовой прозрачности, конфликта интересов, корпоративной финансовой отчетности и др.

Разделы Sarbanes-Oxley Act (SOX) (Закона Сарбейнса-Оксли)

Раздел I. Совет по контролю за аудитом и отчетностью публичных компаний

Раздел II. Независимость аудитора

Раздел III. Ответственность компаний

Раздел IV. Дополнительные требования к раскрытию финансовой информации

Раздел V. Конфликт интересов аналитиков

Раздел VI. Ресурсы и полномочия Комиссии по ценным бумагам и биржам

Раздел VII. Исследования и отчеты

Раздел VIII. Уголовная ответственность за мошенничество

Раздел IX. Ужесточение наказаний за преступления должностных лиц

Раздел X. Налоговые декларации компаний

Раздел XI. Корпоративное мошенничество и ответственность

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

SAP BusinessObjects Planning and Consolidation для SAP NetWeaver или Microsoft: различия (1)

Комментарий от  

Михаил Савкин

  |  13 декабря 2011, 05:43

SAP и Business Objects выпустили масштабное обновление семейства совместных продуктов в области управления эффективностью бизнеса (enterprise performance management, EPM). Ключевой особенностью нового решения, по заявлению разработчика, является тесная интеграция между решениями в области стратегического управления, бизнес-анализа и управления рисками (governance, risk and compliance, GRC), основанная на использовании технологических платформ SAP NetWeaver и Microsoft. Наличие значительного количества новых продуктов, их версий и вариантов их технологических реализаций, на мой взгляд, существенно расширяет возможности автоматизации различных бизнес-процессов компании, но при этом существенно осложняет процесс построения оптимальной архитектуры решения. В этой связи рассмотрение вопросов связанных с описанием процесса развития продуктов SAP BPC для различных технологических платформ является крайне актуальным.

С прикладной точки зрения использование SAP BusinessObjects Planning and Consolidation позволит получить для предприятия следующие преимущества:

  • Удобные возможности для принятия управленческих решений. С учетом возможных рисков необходимо четкое понимание вариантов развития событий и соответствующих действий, которые следует предпринимать в той или иной ситуации.
  • Руководители финансовых и производственных отделов получают возможность совместной работы в единой среде, в результате ускоряется процесс разработки и утверждения планов и бюджетов.
  • Максимально возможное уменьшение коммерческих рисков: прозрачные финансовые показатели, достоверность и доступность, единая версия данных приводят к быстроте и точности управления, формирования отчетности с учетом существующих требований.
  • Улучшенная совместная работа: т.е., применяя предварительно сформированные структурные схемы и последовательность существующих операций, можно значительно сократить затрачиваемое время усовершенствованием используемых бизнес-процессов.
  • Повышение производительности пользователей: интуитивно понятный и привычный интерфейс, возможность интеграции с офисными приложениями (Microsoft Office (Exel, Word, Power Point)) способствуют более рациональному использованию рабочего времени.
  • Минимальное время обучение конечных пользователей.

Также 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 является надежным инструментом для планирования и консолидации, который способен выполнить любые задачи, связанные с бюджетированием, планированием, консолидацией или отчетностью, обладает функциями, необходимыми для распределения финансов и заданий в двух направлениях по иерархии предприятия, а также для консолидации, необходимой для своевременного и максимально успешного завершения финансового периода и при этом обладает неограниченной гибкостью при выборе оптимальной технологической платформы.

Выравнивание оплачиваемых счетов-фактур с помощью функциональности обработки платежных поручений (3)

Комментарий от  

Александр Скородумов

  |  13 декабря 2011, 05:40

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

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

Автор описывает в статье два механизма – ручное выравнивания через транзакцию F-44 и автоматическое, в момент загрузки и разбора банковской выписки. Для большого количества исходящих платежей ручное выравнивание, конечно же, не очень удобно. Я бы предложил отслеживать, чтобы банк возвращал номера исходящих платежных поручений в одном из полей выписки и делать выравнивание в момент загрузки выписки. Однако и в этом случае могут возникнуть также сложности. Дело в том, что при анализе выписки система может искать номер платежного поручения необычным алгоритмом. Сначала анализирует все встречающиеся числа, разделенные любым нецифровым символом и заносит такие во внутреннюю таблицу. А потом каждое число из этой внутренней таблицы подлежит проверке, не является ли оно номером необработанного платежного поручения. Если такое платежное поручение существет, то создается запись в таблице FEBCL «Клиринговые данные к отдельной позиции ЭлектрВыпискиИзСчета». Проблема возникает в том случае,когда в выписке встречаются разные другие числовые значения (например, специальные внутренние номера банка) и если эти значения случайно совпадают с номером существующей необработанной платежки. А этом случае система будет пытаться выравнить существующую позицию с этим платежным поручением. Естественно, неудачно. Это редкий случай но тем не менее, он может встретиться на практике.