Tien Tzuo é fundador e CEO da Zuora. Anteriormente, foi diretor de estratégia e diretor de marketing da Salesforce.com.

http://www.linkedin.com/news?actionBar=&articleID=5573663324144406535&ids=0RcPkSc3gQd34QczcPdzoPdPkRb3oQdPsPc34Rc3sPcPwVcjgTdjkIcz8Vdj0ScjgTdPgNdzgNd3sRdiMTcjcSdzAMdPoPcz4Ne3cOdPkRb3oPcj4Rc3sVe3APcz8MczgTdjkIdjkPd3kMc3oTejASd3wRcPsRdiMUdzATc34Mcz0N&aag=true&freq=weekly&trk=eml-tod2-b-ttl-6&ut=0SdR2AKHt31581



Tien Tzuo: Um momento de silêncio para ERP.
Muito se tem discutido sobre a aquisição pendente da SAP $ 3.4b da SuccessFactors, e agora tratam da Oracle $ 1,9 bilhão para comprar Taleo.Justamente, a SAP ea Oracle têm sido elogiados por tentar reforçar suas ofertas de cloud com esses movimentos. Mas, em poucos anos, eu me pergunto se ele vai realmente importa. Porque, enquanto a SAP ea Oracle estão obviamente tentando começar com os tempos, oferecendo os seus serviços através da nuvem, pode ser tarde demais. Por quê? Porque, em suma, ERP - enterprise resource planning software - está em seu leito de morte.
É isso mesmo. Dia de ERP estão contados. E é por causa de uma mudança fundamental que está ocorrendo em relação a como as pessoas consomem produtos e serviços conduzidos pelo enorme crescimento da nuvem em si.
Estou me referindo à mudança que estamos experimentando de distância de um século 20 baseada no produto, "comprar tempo" para uma economia do século 21 "Economia Assinatura" baseada em serviços centrada em torno de relacionamentos com clientes recorrentes.
Pense nisso: há uma boa chance de você é uma explosão do número de consumidores que agora acessar suas músicas através de uma assinatura, como Pandora ou Spotify. Talvez você seja uma das muitas pessoas que pararam de alugar DVDs em favor da transmissão dos seus filmes mais de Netflix. Ou, você poderia ser um do crescente número de consumidores que têm evitado possuir um carro para aceder a um através de uma assinatura com Zipcar. Ou, talvez você é uma lista crescente de empresas que estão votando "não" para a compra de hardware e software e, em vez estão usando aplicativos e poder de computação servidos a partir da nuvem. Como uma economia e uma cultura, nós estamos rapidamente nos movendo para longe de possuir bens tangíveis e, em vez disso, gravitando em direção a tornar-se membros dos serviços que nos fornecem experiências - como ouvir uma música, usando um carro, assistindo a um filme ou colaborando com a nossa colegas.
Claro, essa transformação cultural tem profundas implicações para os modelos de negócios. Por quê? Sucesso não é mais medido pela contagem de quantas unidades do seu produto você vendeu. Pelo contrário, o sucesso é medir quantos clientes estão usando o seu serviço em uma base recorrente e como bem sucedido você é monetizar essas relações recorrentes.
Hoje, a economia Assinatura está alimentando grandes mudanças em toda a comunicação, mídia, tecnologia, serviços ao consumidor e outras indústrias bilhões de dólares que estão adotando modelos de receita de assinatura.Além dos nomes acima, as empresas inovadoras que adotaram os modelos de negócios de assinatura para transformar radicalmente suas indústrias incluem Salesforce.com, Box, Tata, VNU Media e Zendesk.
Mas, não é apenas as novatas que estão alavancando o modelo de assinatura. A maior indicador dessa mudança é que as empresas de produtos tradicionais como Dell estão correndo para reinventar-se em torno de serviços. Dell reconheceu que a venda de baixa margem de hardware era simplesmente muito menos lucrativo do que oferecer serviços.Consequentemente, a Dell adquiriu empresas de serviços e reorientou seus esforços em torno de "precificar nossos produtos com base no valor, em vez de baseadas no custo", de acordo com Michael Dell. E ele está trabalhando.Em uma recente chamada salário Q3, Michael Dell afirmou: "Este é um Dell novo ... no 3 º trimestre, nossas soluções empresariais e de negócios de serviços cresceu 8% para um nível recorde $ 4,7 bilhões."
E a Dell é apenas um dos muitos titãs da indústria que se deslocou para um modelo baseado em serviços. De acordo com um recente relatório do Gartner Group, "até 2015, 35% das empresas Global 2000 com não-produtos de mídia digital vai gerar receita incremental de 5% a 10% através de serviços baseados em assinatura e modelos de receita."


Por que tudo isso o sinal de morte de ERP? É porque os sistemas rígidos de ERP da SAP, Oracle e outros foram projetados especificamente para a era do século 20 de fabricação e não o mundo do século 21 baseada em serviços. Porque ERP foi construído para rastrear os produtos que podem ser colocados sobre um estrado, versus oferta de serviços que são consumidos ao longo do tempo, as empresas de subscrição que utilizam esta luta tecnologia legada uma e outra vez com as questões fundamentais:
Quem são meus clientes? Tente perguntar a SAP ou Oracle quantos clientes ativos você tem a qualquer momento. O conceito simplesmente não existe.Ordens, contas e produtos? Claro. Pergunte ao seu ERP quanto de up-sell negócio que você fez, ou quantos clientes têm renovado no ano passado - e você vai ter um olhar vazio. ERP não é simplesmente construída em torno de operações centradas no cliente. Em uma economia de Assinatura, a menos que você pode rentabilizar o relacionamento com os clientes ao longo do tempo, você está morto na água.Como posso preço desse serviço, a maneira que eu quero? Serviços de assinatura variam desde simples encargos mensais, para as tarifas de uso base, para um tempo de encargos, para "todas as opções acima." Infelizmente, as empresas de ERP sistemas de força de recorrer a soluções alternativas hokey para obter o seu preço certo, como a criação de diferentesprodutos para cada mês do ano. "Fevereiro de Serviço SKU" alguém? E preço de custo acrescido simples não se aplica aos serviços. Em vez disso, as empresas querem fazer o teste rápido AB preço ao tentar medir o apetite para um novo serviço ou oferta. Enquanto isso, uma mudança de preço único em um sistema ERP pode levar semanas.Onde está o "Renew" botão? Assinaturas são todos sobre um ciclo de vida em constante mudança como clientes inscrever-se, atualizar add-on, e, finalmente, renovar o seu serviço. Em sua essência, os sistemas ERP só dar-lhe um botão "Comprar" para as operações de rastreamento. Estão faltando as ferramentas críticas que você precisa para processar este ciclo de vida longo do tempo.Por que não posso vender para todo mundo? Empresas como a Salesforce.com Assinatura Economia e Caixa tiveram sucesso com a venda de seus serviços a todos, desde usuários individuais até empresas de grande porte. Eles precisam de ferramentas para gerenciar coisas como pagamentos de alto volume recorrentes no mundo B2C, bem como ferramentas para o gerenciamento de alta complexidade facturas e contratos no mundo B2B. E essas ferramentas precisam gerenciar clientes que podem vir através de diferentes canais, tais como web de auto-atendimento, dispositivos móveis, vendas diretas ou canal ou até mesmo no Facebook.Legado da tecnologia da empresa faz com que você escolheu um ou outro, quando o que você realmente precisa é a capacidade de vender B2Any.O que está acontecendo com as minhas finanças? Empresas Assinatura viver ou morrer pela sua capacidade de medir as maneiras que as reservas, faturamento, fluxo de caixa e receita estão inter-relacionados. Infelizmente, esses dados vive em silos de software diferentes. Reservas caem em CRM, faturamento e fluxo de caixa viver em seu GL ou sistema de ERP, ea receita é muitas vezes calculado em uma série de planilhas complexas. Boa sorte amarrando tudo isso junto.É por todas estas razões que os dias de ERP são numeradas. A Economia Assinatura exige novas formas de medir tanto e monetização de relacionamento com o cliente. As empresas devem romper com os grilhões do ERP, se quiserem ter sucesso neste novo mundo. Ou, o risco de ser enterrado ao lado dela.

Fighting Project Manager Stereotypes

PMI Community Post

--------------------------------------------------------------------------------------------------

Fellow project managers: Who are we?

Are we the paper pushers and process police, as an article in this month's PM Network® magazine is titled?

Do we really obsess over reports, come across as control freaks or do everything "by the book"?

Even though most project managers deny they fit these stereotypes, perception is reality for your stakeholders and team members. You may have to fight these false perceptions. Or maybe you need to examine your attitude.

Fight Back!
Do your team members or stakeholders really feel they are drowning in reports? Work with your organization to see if it´s possible to minimize the volume of project documentation.

Then, clearly communicate the importance of basic reports for the project, particularly for monitoring and controlling, risk management or future lessons learned.

Project managers who are seen as controlling should contemplate a change in attitude. Consider adopting a "servant leader" mentality. Try to transfer your responsibility from making decisions for the team to coaching them so that they can make their own decisions.

Project managers always need to be open to new ideas. Ideas about these new ways of working may come from books, journals, your team or other project managers. Creativity should always be part of the equation—and that can help fight a project manager’s "straight-laced" reputation.

How Your Organization Can Help
Organization executives and project managers themselves can do their part to put to rest any misconceptions about their project managers.

Education of stakeholders and team members will help—perhaps you, as the project manager, could initiate that. Additionally, professional and personal development can assist project managers who might see a little truth in their labels.

Everyone Stereotypes
Of course, stereotypes can go both ways. Software developer Kenneth Ahlstrom posted a 3 x 3 matrix on hisblog that, somewhat tongue in cheek, noted that project managers might view developers as "unthinking assembly-line workers," designers as "unthinking assembly-line slave workers with paintbrushes" and themselves as "leaders of the free world with all of the ideas and know-how."

Mr. Ahlstrom had a remedy for all this labeling: Understand your own role and respect the roles of others. "Resentment sets in when one group or another attempts to infringe on another group's job."

Guido Schoonheim, CTO at Xebia, an IT services firm based in The Netherlands, advised project managers to "Provide structure and process while promoting personal initiative. Deliver on time and budget while keeping your team happy and healthy. It is your job to find the appropriate balance between these forces and thereby avoid these stereotypes."

Mr. Ahlstrom concluded that if everyone learns to "trust, respect and value each other, the stereotypes... will continue to fade and our projects together will reach heights never before imagined."

Is this you?

Blogger Kailash Awati, co-author of The Heretics Guide to Best Practices, presents these project manager caricatures:

Barry Bureaucrat: Barry has a form for everything and is a master of fine print.
Conroy Cowboy: Con has a strictly shoot-from-the-hip approach. He reacts fast to events, even if that means there's no thought preceding the action.
Igor Inflexible: Once he has an opinion, he's congenitally incapable of changing it.
Mac Machiavelli: Mac's a schemer. To him, the project and team are important only in how they serve his relentless pursuit of fame and glory.
Norman No–decision: Norm enjoys discussing issues and analyzing them. He’s elevated analysis paralysis to a fine art.
Sally Shifter: Sally has an unblemished record as a project manager because she's good at shifting the blame for mess-ups on to other people, generally her team members.

Do you deal with these people?
Mr. Awati also wants you to know what stakeholders look like:

Andrew Astronaut: With all the big-picture stuff to look after, your project is just a small speck of inconsequence for him.
Charlie Count-the-cash: Charlie sees the project as a black hole for company cash. To counter this, he has a bag of tried and tested money-saving devices.
Devlin Details: He's the kind of sponsor for whom the 50-page progress report (and the 500-page business case) was invented.
Len Leftfield: Len's questions may not be relevant, but they're always clever and, of course, unanswerable.
Mick Micromanager: Mick likes to see the "small picture" or the "trees for the forest," and offer unsolicited advice on project planning and execution.

"Stereotypical behavior generally occurs in dysfunctional environments where stakeholders assume adversarial attitudes that lead to conflict rather than cooperation," said Mr. Awati. "The key to avoiding such problems is to reconcile diverse viewpoints upfront so that all stakeholders have a shared understanding of project goals and a shared commitment to achieving them."

GO HORSE (XGH) - Gestão da Escopo

Fonte: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-gestao-da-escopo.html?spref=bl
Os burocratas do PMI inventaram um monte de baboseiras para gerir o escopo do projeto… WBS, declaração do escopo, blá, blá, blá…

O Go Horse não perde tempo com asneiras como essas, pois se preocupa com o fundamental: ganhar a conta do cliente.

Não adianta perder tempo com previsões e futurologia… tem que dizer para o cliente que tudo o que ele quer vai ser entregue no prazo que ele deseja – só assim se ganha a conta. Depois, se dá um jeito pra fazer tudo – basta jogar a bomba no colo da equipe do projeto.

O gerente de projetos Go Horse deve submeter a sua equipe a um estado permanente de terror, de modo que a mesma trabalhe horas extras para cumprir oescopo, não apenas sem reclamar, mas pensando que não faz nada além da obrigação.

Às vésperas da entrega do projeto, após várias madrugadas de trabalho (por parte da equipe, não do gerente, claro), entrega-se o escopo completo, mas nas coxas. Enquanto o cliente testa, o time segue corrigindo os erros que sabe que existem. Perda de tempo zero, sucesso total.

GO HORSE (XGH) - Gestão das Aquisições

Fonte: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-gestao-das-aquisicoes.html?spref=bl
Essa é uma área que os chatos do PMI se esforçaram para encher de inutilidades. Papéis, papéis, papéis, documentos inúteis…

O PMBOK propõe um processo burocratizado e custoso para realizar concorrência de fornecedores. Ora, para que tudo isso se um parente ou amigo seu pode fazer o trabalho terceirizado? Quem sabe, se você contratar a empresa de um parente, pode até levar um por fora!

É mais ou menos como fazem os políticos no Brasil: preenchem os cargos em seus gabinetes com suas esposas, filhos e afilhados, afinal de contas, quem pode ser mais confiável do que a família, não é mesmo?

Enquanto o PMI condiciona a decisão de fazer ou contratar um serviço à capacidade da empresa de executá-lo, o Go Horse vai pelo caminho inverso: condiciona a sua capacidade de realização à existência de um amigo que faça o serviço!

GO HORSE (XGH): Gestão da Comunicação

Fonte: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-gestao-da-comunicacao.html?spref=bl

A comunicação talvez seja a área de conhecimento que demandou dos burocratas do PMI a maior parcela de criatividade.

Comunicação deveria ser simples: vai lá e fala pro cara o que ele tem que fazer! Mas não: pessoas perderam seu tempo precioso produzindo páginas e páginas com instruções sobre como burocratizar aquilo que a humanidade faz desde os seus primórdios, que é comunicar-se.

Planejamento da comunicação, atas de reunião, relatórios de desempenho, blá, blá, blá… para quê tudo isso se basta passar a informação ao interessado?

O Go Horse acredita em duas ferramentas para comunicação:

- Capacidade de compreensão do ouvinte: para bom entendedor, meia palavra basta. O que dizer de uma palavra inteira? É só falar para o cara o que ele tem que fazer e pronto!

- Poder na estrutura hierárquica: se o ouvinte não faz a tarefa direito porque (diz que) não entendeu, ou que ninguém pediu nada daquilo para ele, basta usar a hierarquia. Palavra de chefe é a verdade, e ponto final. Isso acaba com qualquer ambigüidade.

GO HORSE - eXtreme Go Horse (XGH): origens

link original: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-extreme-go-horse-xgh.html

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

"Go Horse" for Project Management

link original: http://aticomoelae.blogspot.com/2011/01/em-tempo-12-go-horse-solucao.html


É comum nas grandes empresas a adoção do conjunto de práticas do PMI para gerencia de seus projetos. O guia PMBOK, ou Project Management Body of Knowledge esta aí na sua versão 4 e detalha, passo a passo, o que deve-se fazer para uma boa gerencia de um projeto. 
O único detalhe... É difícil faze-lo funcionar na nossa realidade!

Todos nós conhecemos e é comum em grandes - pequenas, médias, etc... - empresas a alta taxa de projetos com falha, na TI então... nem se fala.Algumas pesquisas* mostram que mais de 60% não entregam o escopo definido, extrapolam seus custos e não cumprem seus cronogramas. Isso não é nenhuma novidade, mas nem por isso as corporações deixam de criar seus PMOs, desenvolver metodologias e manuais e obrigar suas equipes, quase sempre pouco qualificadas, a formalidade e a exatidão do PMBOK. Inevitavelmente, a união de todos estes fatores levam os projetos ao fracasso ou aquela percepção de que "poderia ter sido melhor"...

Mas... vem que aparece o Go Horse. Esse sim, largamente utilizado nas empresas. O interessante desta 'metodologia' é que na maioria das vezes nem seus executores percebem que a utilizam.
 

Qualidade??? Para o Go Horse, qualidade é simples: tem que fazer direito a porra do trabalho!

Pesquisando... identifiquei que este assunto não é nada novo, escritos antigos e depoimentos de programadores Fortram aposentados mostram que desde a criação do PMI e da Informática como conhecemos, o Go Horse já era utilizado com sucesso. 

Mas meus amigos, o objetivo daqui é somente introduzir o assunto e induzir o estudo. Por isso não vou escrever parágrafos ou mais opiniões sobre o GH. "Realmente Funciona!!!!".