Os jornalistas e o BPMN, o que ?

O profissional de Implementação BPMN e a realidade... e os jornalistas ?

Frequentemente nos deparamos com questões a respeito das habilidades e conhecimentos do Analista de Processos, também chamado de Analista de Negócios ou ainda de Analista de O&M (Organização e Métodos), o que nos leva a crer que não é clara a descrição do perfil para este papel e nem seja consenso no mercado a definição de suas atribuições e responsabilidades. A partir de uma visão ampla do que é a Gestão de Processos de Negócio (BPM – Business Process Management), percebemos a necessidade de adequação nas responsabilidades deste profissional, cada vez mais necessário nas organizações.

O Analista de Processos ainda é visto em algumas empresas como um cargo meramente operacional, dedicado a executar demandas de mapeamento e/ou desenho dos processos atuais, sendo conhecido por estar rodeado de fluxos e matrizes de impacto. Porém, com a crescente competitividade e busca por soluções visando uma maior constância das organizações, hoje o mercado demanda um profissional de processos com ampla visão estratégica, foco no negócio da empresa e que seja o elo de ligação entre as áreas de negócio e as áreas de apoio, como TI e RH, não apenas transmitindo necessidades das áreas interessadas, mas como um facilitador da comunicação entre as partes.

Este profissional deve expandir a abrangência do seu papel atual, tendo como objetivo sempre a busca pela melhoria do resultado dos processos e, conseqüentemente, da empresa, procurando assim integrar os objetivos organizacionais com os objetivos dos processos da cadeia de valor da empresa. Para isto, é necessário que ele identifique e implante melhorias tanto nas atividades manuais (processos e pessoas) como também através de automações, tarefas estas que só se tornam possíveis mediante a integração e envolvimento no trabalho das áreas envolvidas. Assim, este novo papel não apenas sugere que o profissional execute suas atividades operacionais de mapeamento, mas que seja um multiplicador e motivador em toda a empresa da importância da Gestão de Processos de Negócio como uma iniciativa contínua de melhoria e parte integrante do modelo de gestão da empresa.

O contexto de atividades deste profissional não podemos esquecer que é derivativo da UML - Unified Model Language que é matemática, exata para apoio em definição de requisitos para construir um software são parte de passos para desde requisitos até o que antecede a implementação, testes e homologação de um software bem construído, a UML deve é consolidou seu lugar o que derivou o entendimento não só por arquitetos de software, engenheiros de software, programadores, administradores de sistema de banco de dados mas por chamados " stakeholders "ou agentes de negócio do projetos onde eles definem os requisitos em nesta classe há camadas e uma delas é o analista de negócio onde empresas tentam antes de escolherem um software pré-pronto a ser customizados dentro de uma framework definida a adequar aos requisitos funcionais com pseudos linguagens que estes especialista em fluxos de negócios e não em fluxo de linguagem de programação, foi assim resumidamente nesta minha tentativa de explicar criada notações derivadas da UML como o BPMN ou Business Process Management Notation com uma carga mais de subjetividade do que a objetividade de diagramas dinâmicos e estáticos da UML.

BPMN to UML to PROGRAM Ok ?  Entenderam ??!!! 

Neste tempo estamos ainda em um momento de transição, é natural que tanto alguns profissionais como algumas corporações ainda estejam se adequando a este modelo proposto.

Há muitas dúvidas neste mercado onde empresas não querem entender que as vezes escolher um software pronto ou desenvolver um próprio há passos que devem seguir e são pulados como um tema  ineterssante como este é  quem controla a internet são os jornalistas que se renderam a internet ou dos "INFORMATAS" que criaram a internet ??  Quem ?  

SAAS é realidade ou não ?

O mundo é quase SAAS...

Tais aplicações “incluem muitas vezes o acesso para muitas equipes de funcionários dispersas, sendo um bom candidato para a implantação de plataformas de SaaS “, escreveu Scavo. Aos serviços de plataformas de RH seguem-se os de CRM e de aplicações de colaboração, com 31% dos pesquisados indicando as duas áreas como tendo prioridade no investimento.

Cerca de 25% dos entrevistados indicaram interesse de uso de ERP no modelo SaaS. “Apesar de os ERP e os sistemas de contabilidade serem a categoria mais amplamente implementada de aplicações de negócios em geral, são menos populares para a implantação de SaaS “provavelmente devido ao fato de estarem “mais enraizados e terem uma abrangência mais vasta”.

Apenas 11% dos participantes do estudo expressaram interesse em serviços de SaaS para suportar relatórios de despesas.

A atomização dos interesses dos compradores de SaaS também se manifesta pelo fato de 24% dos entrevistados terem assinalado a categoria “Outros”.

No geral, a adoção de SaaS está crescendo devido aos seus benefícios de acesso, segurança, menos volatilidade em manter o hardware necessário. Os entrevistados assinalaram a velocidade de implantação como o benefício principal, seguido pela redução das infraestruturas de TI, a maior facilidade de expansão e de atualização, de acordo com o estudo.

No entanto, classificaram a disponibilidade e as capacidades de Disaster Recovery como sendo menos importantes quando se trata de SaaS, acrescenta o estudo. “Os fornecedores de software tradicional argumentam que , no longo prazo, a sua oferta muitas vezes custa menos do que as aplicações em SaaS “, o que hoje uma empresa quer usar e se manter com sistema desktop, se ela pensa assim em seu plano imagine na execução.

“É possível que os decisores de TI acreditem nesse argumento” Será ?  

Os preços de subscrição, marca registada do SaaS, não estão bem classificados na lista dos maiores benefícios swgundo os participantes do estudo. Pode haver uma razão para isso, também: os fornecedores de serviços de cloud “argumentam que a subscrição transforma os gastos com software em uma despesa operacional, e para algumas empresas isso proporciona um quadro fiscal mais favorável “, afirma ele. “No entanto, os fornecedores de software instalado localmente também podem facilmente fornecer o mesmo benefício, financiando a compra de licenças de software como um aluguel”.

No topo das preocupações dos entrevistados com o modelo SaaS, estão os riscos de privacidade dos dados – a maior preocupação –, seguido por outras questões de segurança, a perda de controle sobre a informação, os desafios de integração e de desempenho.

Day by day as Software Architecture, not easy..and mistakes

Software Architecture Mistakes

1. Scoping Woes. "This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality...It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation?"
2. Not Casting Your Net Widely. "A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention."
3. Just Focusing on Functions. "…unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful."
4. Box and Line Descriptions. "There are two reasons why the [single, all inclusive] huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean."
5. Forgetting That It Needs to be Built. "Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working."
6. Lack of Platform Precision."…its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work."
7. Making Performance and Scalability Assumptions. "Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design."
8. DIY Security. "A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea. While most of us think we could probably whip up a clever piece of security technology in no time, we’re usually wrong."
9. No Disaster Recovery. "The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it."
10. No Backout Plan. "Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment."

About SQL Command Insert " large number rows "

Many friends Software Architect, DBA, QA Analyst questions about SQL Insert " large" ?

( Oracle Database )

Question:  What are the steps for tuning an insert SQL?  

It's running far too long and I need to understand how to optimize the insert for performance. 

Answer:  Many factors that effect Oracle insert SQL performance and many things that you can do to tune an insert statement.  When loading large-volumes of data, you have several choices of tools, each with their own costs and performance benefits. 

Some insert tuning techniques that can work in a multitude of workloads.  Remember, you can have choices for doing table inserts including the Data Pump and SQL*Loader utilities, as well as PL/SQL bulk load tools such as theforall operator There are many types or Oracle inserts, each with distinct performance characteristics:

=======================================================================

The fastest Oracle table insert rate I've ever seen was 400,000 rows per second, about 24 million rows per minute, using super-fast RAM disk (SSD), but Greg Rahn of Oracle notes SQL insert rates of upwards of 6 million rows per second using the Exadata firmware:

"One of the faster bulk (parallel nologging direct path from external table using direct path compression) load rates I've seen is just over 7.7 billion rows in under 20 minutes which equates to around 385,000,000 per minute or about 6,416,666 per second.

All the CPUs are running at around 99% user CPU during that load. That was loading to spinning rust (Exadata Storage). It would be even faster had compression not been used. That was on a HP Oracle DB Machine (64 Intel Harpertown CPU cores). "

While my complete notes are found in my book "Oracle Tuning: The Definitive Reference", I have my main notes on tuning inserts here, but here are some general guidelines for tuning inserts statements. 

a - Disable/drop indexes and constraints - It's far faster to rebuild indexes after the data load, all at-once. Also indexes will rebuild cleaner, and with less I/O if they reside in a tablespace with a large block size.

b - Manage segment header contention for parallel inserts - Make sure to define multiple freelist (or freelist groups) to remove contention for the table header. Multiple freelists add additional segment header blocks, removing the bottleneck.  You can also use Automatic Segment Space Management (bitmap freelists) to support parallel DML, but ASSM has some limitations.

c - Parallelize the load - You can invoke parallel DML (i.e. using the PARALLEL and APPEND hint) to have multiple inserts into the same table. For this INSERT optimization, make sure to define multiple freelists and use the SQL "APPEND" option.  Mark Bobak notes that if you submit parallel jobs to insert against the table at the same time, using the APPEND hint may cause serialization, removing the benefit of parallel jobstreams.
 

d - APPEND into tables - By using the APPEND hint, you ensure that Oracle always grabs "fresh" data blocks by raising the high-water-mark for the table. If you are doing parallel insert DML, the Append mode is the default and you don't need to specify an APPEND hint.  Mark Bobak notes "Also, if you're going w/ APPEND, consider putting the table into NOLOGGING mode, which will allow Oracle to avoid almost all redo logging."
insert /*+ append */ into customer values ('hello',';there');
 

e - Use a large blocksize - By defining large (i.e. 32k) blocksizes for the target table, you reduce I/O because more rows fit onto a block before a "block full" condition (as set by PCTFREE) unlinks the block from the freelist.

• See benchmark test of blocksize and inserts here
   
• See general benefits of multiple blocksizes here

f - Use NOLOGGING

f - RAM disk - You can use high-speed solid-state disk (RAM-SAN) to make Oracle inserts run up to 300x faster than platter disk.

Insert performance (blocksize)

When begin test, action,  my small single-CPU, single-user benchmark showing the performance of loads into a larger blocksize:

alter system set db_2k_cache_size=64m scope=spfile;
alter system set db_16k_cache_size=64m scope=spfile;
startup force
create tablespace twok blocksize 2k; <-- 100m="" asm="" br="" defaults="" to="" using="">create tablespace sixteenk blocksize 16k;
create table load2k tablespace twok as select * from dba_objects; < creates 8k rows
drop table load2k; <- br="" buffers="" create="" first="" preload="" to="" was="">

set timing on;
create table load2k tablespace twok as select * from dba_objects;
create table load16k tablespace sixteenk as select * from dba_objects;

For a larger sample, I re-issued the create processes with:

select * from dba_source; -- (80k rows)

Even with this super-tiny sample on Linux using Oracle10g (with ASM) the results were impressive, with a significant performance improvement using large blocksizes.

             2k        16k
      blksze         blksze
8k table size   4.33 secs     4.16 secs  
80k table size   8.74 secs     8.31 secs 

Optimizing Oracle INSERT performance

The fastest Oracle table insert rate I've ever seen was 400,000 rows per second, about 24 millions rows per minute, using super-fast RAM disk (SSD).

Speed of inserts is primarily a function of device speed, but NOLOGGING, maximum parallel DML (which, in turn, a function of the number of CPU's and the layout of the disks) also factor into the equation. When using standard SQL statements to load Oracle data tables, there are several tuning approaches: 

Using SSD for insert tablespaces

For databases that require high-speed loads, some shops define the insert table partition on solid-state disk (later moving it to platter disk).  Mike Ault notes in his book "Oracle Solid-State Disk Tuning", a respectable 30% improvement in load speed:

“In the SSD verses ATA benchmark the gains for insert and update processing as shown in the database loading and index build scenarios was a respectable 30%.I
This 30% was due to the CPU overhead involved in the insert and update activities.
If the Oracle level processing for insert and update activities could be optimized for SSD, significant performance gains might be realized during these activities."

Today I hear in business  about many problems about development ERP Project and Software Companies with deliveries, these software projects , I believe next 10 years ERP will change with back of development into components, what is it ? Development about customizations  with components of Software Architecture as SAP, TOTVS, SENIOR SISTEMAS, ORACLE with one platform as years old, all requirements of users, stakeholders to ERP implementation and one delivery with major probability of success, is possible ???   Failures inflict a great deal of pain on company, senior management of the companies have to do their homework to hire a project manager of Information Technology who have experience in software development.

Whether it’s implementation cost overruns, software that doesn’t support the business, or lack of employee acceptance, ERP failures entail very negative consequences. So why do over 65% of enterprise software implementations fail? 

Some Lessons from ERP Implementation Failures

ERP implementation failures inflict a great deal of pain on organizations. Whether it’s implementation cost overruns, software that doesn’t support the business, or lack of employee acceptance, ERP failures entail very negative consequences. So why do over 65% of enterprise software implementations fail?

Our experience helping clients clean up projects they or their software vendors have failed to manage, along with our expert witness support to ERP lawsuits, has taught us quite a bit about the reasons for ERP failure. 

Below are five trends we see in most troubled enterprise software implementations:

1. Lack of software fit. The first stumbling  block formany failed implementations is as ever emis alignment between software functionality and business needs. There are hundreds of enterprise software options in the marketplace, so it is important to navigate carefully and find the product with the right fit. Too many failed implementations neglected to engage in an effective ERP software selection process. 
2. Unrealistic implementation expectations.  Enterprise software sales reps often understate the level ofre sources required to make the implementation successful, so many companies fail to budget adequate time, money, resources, and external consulting support to make the project successful. In addition, failed implementations often neglect to include key activities in their implementation project plan, such as organizational change management, business process and workflow definition, and thorough conference room pilots.
   
3. Lack of executive buy-inand support. Executive buy-in involves more than signing the checks and delegating the implementation to a project team. It involves defining clear implementation objectives, establishing project governance, and making tough decisions when needed. This is arguably the most important, because it directly affects the other four failure points.
   
4. Propensity to customize software rather than leverage standard functionality.Nearly every failed implementation I have seen suffers from this problem, and it is often because of a failure to select the right software in the first place (see #1 above). The more you customize the software, the longer it’s going to take to implement, the more it’s going to cost, and the more risk you introduce into the project. It’s typically not realistic to completely abstain from customization, but changes to the software should be devoted only to key areas of competitive advantage or differentiators. If you aren’t able to limit customization to those areas, then you should either find another ERP software solution or back up and rethink your strategy.
   
5. Lack of ERP implementation expertise.Implementations are tough and a team with tested battle wounds is going to dramatically increase your likelihood of success. As we often tell our clients, the fastest and cheapest way to implement enterprise software is to do it right the first time. Failed implementations are more likely to have inexperienced team members who don’t know enough to know what they don’t know.

Na real, no mundo real do "Planning"

ERP na prática...real.  Enterprise Resource Planning what ? 

Será que os gestores conhecem que  palavra ERP tem um "P" de Planning ou Planejamento ?!

Nas metas de uma empresa hoje uma delas é ter um fluxo de informação definido e claro, desde seu ambiente de produção de produtos até ao seu escritório que normatizam o dia a dia dos setores financeiros, fiscal, recursos humanos. 

É necessário muitos ajustes em infra-estrutura de Tecnologia da Informação (TI) para receber os pacotes de gestão empresarial (ERP) são normais. 

No entanto, antes de qualquer decisão, rumo à substituição total de microcomputadores, servidores e equipamentos de rede, é preciso observar o que pode ser reaproveitado. Especialistas indicam que se aproveite ao máximo o que esteja implementado em casa e a própria experiência prévia com sistemas integrados do tipo ERP.

Mas como isso pode ser feito? A primeira ação é radiografar a infra-estrutura, não só o que se tem hoje, mas também o que seria desejável com a entrada do pacote de gestão, como forma de planejar os investimentos necessários. Processos de tecnologia bem-definidos para a adoção do pacote de gestão são extremamente importantes, pois eles facilitam os ajustes da infra-estrutura. Como processos, entendam-se abordagens e diretrizes tecnológicas, entre elas a padronização de sistemas operacionais e a uniformização da compra de equipamentos.

Um possível impacto negativo dos sistemas e máquinas legadas – que já existem na empresa – pode ser minimizado com a compra de softwares de integração, responsáveis pela ponte entre o ERP e o que a empresa já tem. Outro aspecto importante que permeia a introdução de um sistema de gestão é o da segurança. Não é preciso montar uma política específica para a área – caso a empresa não a tenha, é claro -, mas é essencial criar diretrizes de concessão de acessos.

Afinal, nem todos os funcionários precisam ou devem acessar o ERP. Outra indicação universal é que, independentemente da infra-estrutura, a empresa mantenha um ambiente de desenvolvimento/testes de implementação do ERP e outro de produção dos sistemas atuais até ter certeza de que o projeto está seguro para ser efetivada a troca.

Ou seja é indicado que qualquer empresa tenha serviços contratados ou tenha um equipe que cuide das seguintes atividades :

1. Desenvolvimento / Customização 

2. Validação de escopo funcional

3. Teste

ERP é um software embora já pronto, mas muito provavél que não entre em sua empresa pronto e aderido ao seu processo...

Case Study on Hershey's ERP Implementation Failure

ERP Implementation Failure

by Jonathan Gross | Mar 9 2011

Imagine waking up one day to find out that your company's supply chain has ground to a halt, making it impossible to fulfill $100 million worth of orders. For Hershey's confectionary manufacturing and distribution operations, this nightmare came true in 1999.

When it cutover to its $112-million IT systems, Hershey's worst-case scenarios became reality. Business process and systems issues caused operational paralysis, leading to a 19-percent drop in quarterly profits and an eight-percent decline in stock price. In the analysis that follows, I use the Hershey's case to offer advice on how effective ERP system testing and scheduling can mitigate a company's exposure to failure risks and related damages.

Here are the relevant facts: In 1996, Hershey's set out to upgrade its patchwork of legacy IT systems into an integrated ERP environment. It chose SAP's R/3 ERP software, Manugistic's supply chain management (SCM) software and Seibel's customer relationship management (CRM) software. Despite a recommended implementation time of 48 months, Hershey's demanded a 30-month turnaround so that it could roll out the systems before Y2K. Based on these scheduling demands, cutover was planned for July of 1999. This go-live scheduling coincided with Hershey's busiest periods - the time during which it would receive the bulk of its Halloween and Christmas orders. To meet the aggressive scheduling demands, Hershey's implementation team had to cut corners on critical systems testing phases. When the systems went live in July of 1999, unforeseen issues prevented orders from flowing through the systems. As a result, Hershey's was incapable of processing $100 million worth of Kiss and Jolly Rancher orders, even though it had most of the inventory in stock.

This is not one of those "hindsight is 20-20" cases. A reasonably prudent implementer in Hershey's position would never have permitted cutover under those circumstances. The risks of failure and exposure to damages were simply too great. Unfortunately, too few companies have learned from Hershey's mistakes. For our firm, it feels like Groundhog Day every time we are retained to rescue a failed or failing ERP project. In an effort to help companies implement ERP correctly - the first time - I have decided to rehash this old Hershey's case. The two key lessons I describe below relate to systems testing and project scheduling. 

ERP Systems Testing

Hershey's implementation team made the cardinal mistake of sacrificing systems testing for the sake of expediency. As a result, critical data, process and systems integration issues may have remained undetected until it was too late. 

Testing phases are safety nets that should never be compromised. If testing sets back the launch date, so be it. The potential consequences of skimping on testing outweigh the benefits of keeping to a longer schedule. In terms of appropriate testing, our firm advocates a methodical simulations of realistic operating conditions. The more realistic the testing scenarios, the more likely it is that critical issues will be discovered before cutover. 

For our clients, we generally perform three distinct rounds of testing, each building to a more realistic simulation of the client's operating environment. Successful test completion is a prerequisite to moving onto to the next testing phase.

In the first testing phase - the Conference Room Pilot Phase - the key users test the most frequently used business scenarios, one functional department at a time. The purpose of this phase is to validate the key business processes in the ERP system.

In the second testing phase - the Departmental Pilot Phase - a new team of users tests the ERP system under incrementally more realistic conditions. This testing phase consists of full piloting, which includes testing of both the most frequently used and the least frequently used business scenarios.

The third and final testing phase - the Integrated Pilot Phase - is the most realistic of the tests. In this "day-in-the-life" piloting phase, the users test the system to make sure that all of the various modules work together as intended. 

With respect to the Hershey's case, many authors have criticized the company's decision to roll out all three systems concurrently, using a "big bang" implementation approach. In my view, Hershey's implementation would have failed regardless of the approach. Failure was rooted in shortcuts relating to systems testing, data migration and/or training, and not in the implementation approach. Had Hershey's put the systems through appropriate testing, it could have mitigated significant failure risks.   

ERP Implementation Scheduling

Hershey's made another textbook implementation mistake - this time in relation to project timing. It first tried to squeeze a complex ERP implementation project into an unreasonably short timeline. Sacrificing due diligence for the sake of expediency is a sure-fire way to get caught.

Hershe's made another critical scheduling mistake - it timed its cutover during its busy season. It was unreasonable for Hershey's to expect that it would be able to meet peak demand when its employees had not yet been fully trained on the new systems and business processes. Even in best-case implementation scenarios, companies should still expect performance declines because of the steep learning curves.

By timing cutover during slow business periods, the company gives itself more slack time to iron out systems kinks. It also gives employees more time to learn the new business processes and systems. In many cases, we advise our clients to reduce incoming orders during the cutover period.

In closing, any company implementing or planning to implement ERP can take away valuable lessons from the Hershey's case. Two of the most important lessons are: test the business processes and systems using a methodology designed to simulate realistic operating scenarios; and pay close attention to ERP scheduling. By following these bits of advice, your company will mitigate failure risks and put itself in a position to drive ERP success.

Source : 

http://www.pemeco.com/resources_center/erp-implementation-importance-testing-and-scheduling