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

Caraterísticas comuns de SOA - Service Oriented Architecture

O princípio da  orientação a serviço, numa aplicação que sua base resulte em processamento padrão controle de sua lógica implementado num paradigma  "orientado à serviço", os cuidados para esta vamos dizer "essência" ser percebida,  as consequências são levemente a soma de todas as ações de forma ordenadas, orquestradas resultam em um serviço ou uma solução, próxima da autonomia orientada a serviço.  Uma proposta para prover um  "HIGHLIGHT" de alguns aspectos chaves de princípios quando o mercado apresenta uma solução já conhecida e agora publica que esta  solução tem novo desenho, nova versão e agora em SOA ou Service - Oriented Architectured  pois  bem, verifiquem, questionem, procurem um bom arquiteto de software para olhar e avaliar o que eles dizem ter, afinal quando temos dor de dente procuramos um odontologista ou "dentista" e quando uma empresa precisa de precisão, definição de escopo, avaliação não funcional e funcional em um software deve-se procurar um "arquiteto" ou seja um arquiteto de software, os demais conhecimentos de como os componentes funcionarão, cada elipse com suas responsabilidades, os serviços a serem automatizados claro que deve ser definido em atividades alinhadas de uma equipe com analistas, testadores, programadores, administradores de dados e objetos.

Alto nível de um rascunho de desenho SOA

Bem vamos lá...o padrão de compreensão da arquitetura de negócio e software básica de uma solução que alinhe os aspectos principais  SOA deve seguir :

1. Baixo acoplamento
2. Contrato de serviço
3. Autonomia do serviço
4. Abstração do serviço
5. Reusabilidade do serviço
6. Orchestrado, Ordenado a uma composição de serviços
7. Fácil descoberta de uso do serviço

Se as empresas pudessem fazer o que deveriam de entender e testar o que podem estar escolhendo, cada conceito de desenho de partes do projeto orientado a serviço, exige muita disciplina neste tema de definição.

A composição dos requisitos funcionais serão boa parte da base de decisão dos serviços isolados, agrupados mas que todos estejam integrados.

Será...que MS-Project 2007 cairá e 2013 subirá?

Até o momento posso escutar e ver muitas movimentações sobre o lançamento do MS-Project 2013, até que esta versão tem boas novidades e finalmente a Microsoft se atenta a dar dinamismo a ferramenta de apoio a gerência de projeto, o mercado usa ainda em sua maioria o MS-Project 2007, portanto as grande mudanças ainda são promessas aos gerentes de projetos, todos os andamentos de "refactory" ou vulgarmente falado de inovações são para convergência para plataforma stand-alone

do MS-Office e integrar a plataformas Server como ao próprio MS-Project Server e Lync. 

Um overview do MS-Project 2013 está disponível no site da Microsoft, dentro da opção de informações do produto, conforme mencionei  foi dada maior ênfase à comunicação e colaboração, permitindo inclusive trocas de mensagens instantâneas, ainda não comparando com um ferramenta de acompanhantes de Gerência de Risco, Portfólio e cronograma de forma dinâmica e integrada a comportamentos que podem ser automatizados, implementados como na suíte de ferramenta da Oracle para Gerência de Projetos como o Oracle P6 Primavera  .

Colaboração 

Algumas das suas funcionalidades estão descritas a seguir :

• O Project Online ajuda você, identificando os passos importantes e fornecendo um guia simples para você configurar as funcionalidades do Project Portfolio Management (PPM). Project Online permite ainda acesso remoto, inclusive com suporte para smartphones e dispositivos móveis.
• Permite um gerenciamento flexível do portfólio de projetos, seleção ótima de portfólios, otimização de cenários, balanceamento da capacidade de recursos e priorização.
• O Project Online continua permitindo o uso da interface Project Web Access (PWA), permite a criação de fluxos de trabalho usando Visio no SharePoint Designer e outras funções de governança e controle no ciclo de vida dos projetos.
• Permite compartilhamento de documentos e outras funcionalidades de colaboração.
• Permite visualizar e customizar painéis, visões, relatórios, resumos e planos para auxiliar na tomada de decisão dos projetos e do portfólio.

Finalmente um dashboard um pouco melhor...

Gestão de Projetos ou navegamos sem mapa ? Como ?

Muitos profissionais que gerenciam projetos na área de TI reclamam : será que vou ter tempo de controlar as minhas atividades registradas num projeto numa ferramenta, seja qual for, já ouviu isto ? 
Mas é verdade temos muitos que dizem...isto ...acreditem ...
Imagina um navegador sem a ferramenta dele..o astrolábio, imagina ?

Astrolábio antigo 

Ou também alguns dizem :  prefiro registrar numa planilha MS-Excel ou  no bloco de notas ou Textedit, bem isto é alarmante! 
Aprender e ter boas práticas de gerência começa na escola dos profissionais ou as ditas academias, obter bons resultados é consequência de uma boa gerência. Com todas as referências dos projetos controlada seja técnica ou não, é necessário registrar as atividades, classifica-las e assim extrair contextos do andamento das resoluções de cada problema do projeto. As visões tem de caminhar, andar juntos ao da ciência e a comercial, para a tecnologia da informação ser absorvida com boas visões. Preocuparmos no dia a dia dos projetos de TI e uma delas é a gerência estar ciente da importância do registro dos passos do projeto, compreendendo o andamento e criando um contexto profissional e não pessoal do projeto, pois qualquer ferramenta de bom nível, conseguirá apoiar estaticamente ou dinamicamente, ferramentas de apoio a gestão de projetos como o MS - Project apresenta controle de informações que podem estar baseadas em adequações seja em padrões do PMI(Project Management Institute) ou do IPA(Independent Project Analysis) ou até de algum método criado pela empresa assim o MS-Project apresentará uma boa perspectiva em agregarmos valor ao serviço executado e conter melhor gestão de riscos, cronograma, metas, recursos. As dificuldades são variadas num projeto de TI, com o perfil que vivemos hoje de ciclos não definidos de profissionais da área, orçamentos escassos, tecnologias em mudança, evolução, pois isto sem uma ferramenta como controlamos ? É um desafio ! Tendo um padrão de trabalho baseada em referências profissionais e acadêmicas, cruzando com a prática de gerentes de projetos que procuram a verdade de cada tarefa a ser executado, para em conjunto terem bons resultados, mitigar os assuntos, temas do projeto e isto contendo dentro de uma ferramenta automatizada que dispara resumos, gráficos com certeza minimizará maus entendimentos e decisões. 
Pensamos como um bom navegador sem mapa sobreviveria no mar ? 

E o caso de um gerente de projeto, um líder técnico, um gestor sem uma ferramenta de apoio, auxílio de registro não é !? Imagina gerentes sem base de direção de suas decisões, e onde esta a base ?  As buscas contínuas em sabermos os pontos de erro, tentarmos estar preventivos aos problemas sem um mapa do projeto, sem uma ferramenta, sem uma equipe técnica de boa vivência e esta sem um guia e sem uma ferramenta guia do projeto como será que seria o resultado ?

Ferramentas atuais de apoio de gestão de projetos em TI, que indico conhecer e usar, para não ficarem a "deriva" :

a. Microsoft Project 2010

b. Oracle Primavera 

c. OpenProject

CYBER segurança em acesso WIRELESS

Redes Wireless podem prover individuais acessos para a internet, isto não importando o local geográfico. Dependendo de suas atividades online, a cada acesso pode existir uma potencial ameaça de insegurança da informação.

Estas possíveis inseguranças são devidos a casos individuais de quem acessa principalmente redes sem segurança, sem origem do funcionamento em espaços públicos, este assunto de CYBER segurança é importante entender para a estabilidade e segurança da informação pessoal e profissional.

O processo de melhoria de uma rede wireless na sua segurança de seguir em ações preventivas de segurança, devendo estar em contextos utilizados e testados no mercado, todos dispositivos que acessam a rede como smartphones, tablets, netbook, laptop devem estar examinados ou pelo menos identificados.

Todas as normas que devem estar aplicados a estas redes privadas, públicas não são aplicadas, devendo o usuário conhecer a origem da rede e investir em configurações preventivas e soluções de bloqueio.

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

Wireless network can provide individuals access to the internet no matter where they are. However, did you know that there is a security threat every time you go online? 

The TSA is in the process of improving its wireless network security following an audit by the Department of Homeland Security (DHS) which covered cybersecurity on devices like Blackberries. The audit examined how well sensitive information was protected on TSA networks, and it revealed that the physical and logical network access controls employed by TSA were effective in avoiding major vulnerabilities.

However, they found weaknesses and vulnerabilities related to patches and configuration controls which needed to be improved. The DHS made some specific recommendations to TSA in this regard, including the importance of revising the patch management process update patches in a more timely way and to enforce security policy on all TSA employes to ensure that every individual had their devices and systems properly secured. TSA has made considerable progress in securing their local area networks since 2000.