Archive | Standards RSS feed for this section

It’s All About Your Niche, Do You WANT to Leave There?

9 Apr

Back to reading my original blog muse, Oleg Shilovitsky.  In a recent blog (“Ugly vs. Cool”) he took PLM vendors to task re: their product user interface.  It got me thinking:

What do my previous company, CIMx Software, and my current company, Vinimaya, have in common?

Although there are many differences, and many other reasons for their success, both software companies are, in part, successful because of the failings of another industry’s functionality and user interface.

Ask any PLM vendor and they will say that they support manufacturing.  Truth be told, they have products designed and built for the design engineer and management of design projects.  The user interface is designed by engineers and for engineers.   The schemas and taxonomies of the PLM system do not support the workings of the manufacturing shop, and the user interface is way too complex for the casual user.  In the case of CIMx  Software, there have been numerous attempts by the engineering organizations at CIMx customers to ‘standard ize’ on the PLM environment for manufacturing and shop floor.  At one particulart customer, there were close to 1/2 dozen ‘pilots’ of the PLM system in manufacturing engineering.  They all failed to provide what CIMx had out of the box.

The same can be said for ERP ‘eProc’ applications and Vinimaya.  If ERP vendors provided simple federated search across all of their internal and external suppliers with a user interface like Google or Amazon, there would be no need for SmartSearch™.   That’s not the case.  eProc systems tend to have the same laborious click-heavy, multi-screen UI issues as most ERP and PLM functions.

Why is this so?  It boils down to two elements, legacy and domain expertise.

1) Legacy.  One of my favorite quotes about the software industry is “God created the universe in six days because he didn’t have an installed base”.  It is extremely difficult for established vendors in a particular space (ERP, PLM) to completely re-write their large monolithic systems.  They can certainly apply a web ‘veneer’ and update icons and other visual elements, but it’s the same old code underneath.

2) Domain Expertise.  I recall the amazement in the voice of a colleague in the MES space when he had to explain to their PLM partner the  concept of a work order.  You may know the technology behind and engineering bill of materials backwards and forwards, but that does not mean your expertise has any value down on the shop floor.

So, where do you want to live, Mr. ERP vendor?  Mr. PLM vendor?  The more you decide to venture outside of your area of core competence, the more you will have to be concerned about functionality and UI, and the less likely you will be able to compete with the likes of CIMx and Vinimaya.

- RTR

Tags: , , , , , , , , , , , , ,

Commenting on Team Building

20 Mar

While I have managed a team at various times during my career, my most recent assignment was more of an individual contributor role, and, I’ve not had to ‘inherit’ a team in quite a while.  With this in mind, I found this blog over at Harvard Business Review to be very interesting.

The blog was called “The Hard Science of Teamwork” reported by Alex ‘Sandy’ Pentland.  The author is the Director of MIT’s Human Dynamics Laboratory and the MIT Media Lab Entrepreneurship Program.   The ‘Hard Science’ in the title refered to the use of ‘sociometric badges’ to mathematically measure communication.  The blog stated with points related to the ‘new science of building great teams’.

Our data show that great teams:

  • Communicate frequently. In a typical project team a dozen or so communication exchanges per working hour may turn out to be optimum; but more or less than that and team performance can decline.
  • Talk and listen in equal measure, equally among members. Lower performing teams have dominant members, teams within teams, and members who talk or listen but don’t do both.
  • Engage in frequent informal communication. The best teams spend about half their time communicating outside of formal meetings or as “asides” during team meetings, and increasing opportunities for informal communication tends to increase team performance.
  • Explore for ideas and information outside the group. The best teams periodically connect with many different outside sources and bring what they learn back to the team.

An interesting point made by Mr. Pentland was that content of communication (the ‘what‘) did not matter as much as they way that communication took place (the ‘how‘).  This makes sense to me.   Material presented in dull monotone will not have the effect as the same material present with passion.

One learning from this blog that did suprise me was Pentland’s assertion that communication (charisma?) can be taught:

In our work we’ve found that these patterns of communication are highly trainable, and that personality traits we usually chalk up to the “it” factor — personal charisma, for example — are actually teachable skills.

This bears watching.  In my new role, an effective team will be key to our continued success, and communication will be a very important factor.

More to come….

- RTR

Tags: , , ,

Is Being Unique Unique? Is Being Unique Enough?

27 Feb

Is anything sustainable and unique?

Yogi Berra once said, “This is like Déjà vu all over again”

John Franzosa once said, “There’s a difference between 20 years experience and 1 year experience 20 times” (actually, my Dad said this a lot more than once).

There is an excitement, a freshness when a child first discovers the things that soon become commonplace.  I especially enjoyed hearing all of those awful corny jokes from my kids when they first discovered ‘humor’ in the 2nd or 3rd grade.

From the reverse perspective, when they become young adults and you, as a parent, begin to look for their perspective? That is also very cool.

At a certain level, we are all unique.  At a certain level we are all the same (I think I learned this watching ‘Sesame Street’ with my kids)…

The point of my topic?

In the world of business, uniqueness can be a red flag.  What we disparagingly call ‘bleeding edge’ technology…

There will always be a subset of companies that are drawn to the ‘bleeding edge’, the “early adopters”.  It is not particularly difficult to attract early adopters.

Many new technology firms start fast out of the chute, only to lose momentum in trying to get to the ‘mainstream’.   Does uniqueness work for or against a company when they hit that lull, when they move from early adopter to mainstream?

Ultimately, I think that companies that just rely on being ‘unique’ will stumble.  What matters in business (and in life, I suppose), is being dependable and adding value.  Don’t get hung up on unique.  We can’t all be Steve Jobs, but we can all be dependable and we can all add value.

- RTR

Tags: , , , , , , , ,

If It’s All About Process, Why Focus On Features?

22 Feb

The following was tweeted from the PLM Conference at the Westin in Munich this morning by Gabriel Gheorghiu:

“Marc Halpern (Gartner) some of the best #PLM implementations done without PLM software. Processes matter most #plm2012“

If this is true, and I believe it is, then why on God’s green earth do companies still go through the same drill, asking for a feature list, looking at features, providing RFIs/RFPs that talk about features (example: 314 features in an RFP that we answered last year).

What do features matter?  It’s ALL ABOUT THE PROCESS.  It doesn’t matter how shiny it is, whether or not it’s on the cloud, what technology platform it runs on.  Here’s all that matters:

Do you have a reliable, efficient process?

Does this software make that process better?

’nuff said

- RTR

Tags: , , , , , , , , ,

Standardization – What’s YOUR job Mr. Software Vendor?

21 Feb

There is a discussion going on over at LinkedIn  about whether or not a single MES system can be used across multiple plants.  The topic of standardization is a hot one.   Individual plants (and individuals) believe that they are ‘different’, that one size does not fit all.  We all believe that we are unique, that no one does exactly what we do.  In the case of manufacturing, there is some truth to that.  Efforts to ‘standardize’ manufacturing have the tendency to stifle creativity.  They also tend toward creeping bureaucracy.

Uniqueness is not always a good thing.  As someone once told me “Do it once, it might be a mistake, do it twice it’s a habit, three times it’s a tradition”.    There are a lot of traditions out there in manufacturing that would lend themselves to retirement.  If the rationale for a process is “But we’ve always done it this way”, then maybe you have to dig a bit deeper.

So what is the software vendor’s job in all of this?  Standardization?  Uniqueness?

In a timeless blog from 2009, David Meerman Scott provided the “Top Gobbledygook phrases used in 2008 and how to avoid them”.  Our friend ‘Unique’ checks in at #3 on the list of most overused phrases in B2B press releases, right after #2 “Pleased To” and #1 “Innovate”….

… but we have all bases covered with #14 Flexible and #18 Scalability!

So, now that we are all pleased to uniquely innovate, what are we really saying here?

The point of my title is that how a software product is designed and implemented goes a long way in balancing the business need for standardization in the face of  the users desire for ”uniqueness’.  Hey, if it was easy, ANYONE could do it!

The key for software vendors is standardization that fosters uniqueness.  What does that mean?  If you’re too unique, you may miss your target.  If you’re approach is ‘forced’ standardization, you aren’t allowing your customers to use their uniqueness to their advantage.

Being unique is a good thing, otherwise we wouldn’t make such a big deal about it in our B2B press releases!  A BETTER thing is to foster the uniqueness that the end-user requires in a structured framework that the business requires.  Give them what they want, make it simple, hide the rules and complexity.  Now THAT’S innovation!  (Sorry, couldn’t resist…)

more here…

- RTR

Tags: , , , , , , , , ,

PLM vs. PDM – Perception vs. Reality

8 Feb

Inge Kraninckx asked a question about the definitions of PDM & PLM in the PLM PDM CAD group on Linked in.

I just read this statement in a Journal by PLMIG (Q3/2010) Do you agree with this definition?

As reaction to the idea that PLM is “scaled up PDM”, and the idea that PDM applies to less of the product lifecycle than PLM, they formulate this definition:
“PDM is the IT platform for PLM.”
Or, expressed from the opposite viewpoint:-
“PLM is the business context in which PDM is implemented.”

I think that the definition really comes down to perception vs reality. 

Our CEO here at CIMx is fond of  saying “perception is reality”  at one point early in our history, it was the tag line on his email signature. 

In the PDM/PLM debate the “perception” of Product LIFE-CYCLE Management is, in my view, significantly larger than the reality.  The reality is that most PLM systems are doing PDM, managing product data via BOM management, engineering change management, vaulting and workflow.  In that regard, PDM [read BOM management, engineering change management, vaulting and workflow], IS the IT platform for the yet unfulfilled promise of PLM.

Some may construe my comments as bashing PLM vendors.  Not true, I believe that Product Life Cycle management is where their focus should be as they grow and mature their products, and I believe that the vendors in that marketplace are working diligently to expand their horizons beyond the comfort of the engineering office. 

In order to support the full product lifecycle, PLM vendors need to invest in domain expertise outside of the realm of engineering (PDM).

This can be done by aquisition (as Dassault has done with the acquisition of Intercim, and Siemens has done with multiple acquisitions, Tecnomatix comes to mind), but acquisition brings it’s own challenges; differences in culture, technology and focus.  

Domain expertise can also be achieved by much less grandiose investments in partnering and/or talent. 

I believe that todays PDM will become PLM, it’s just a matter of time.

- RTR

Tags: , , , , ,

Commenting on Cloud Cartels

31 Jan

Interesting technology blog over at the New York Times today.  The blog is commenting on a Forrester business and technology outlook report for 2020.  … and 2020 is not too many years away!  In summary, the Times blogger said

“The short version is that cloud computing will come on quicker than you think, it will be controlled by a very few companies that will fight for the right to own your data, and businesses need to think about what software they can write that will differentiate them from all the other customers of these giants.”

The only thing constant here is change.  Here’s a few names for you:  Digital Equipment Corporation (DEC), Data General, Sperry Univac.  The titans of the computer industry.  I personally attended a DECWorld extravaganza in Boston ‘back in the day’.  DEC took over Commonwealth Pier in Boston,  leased two ocean liners (the “Queen Mary” and the “Norwegian”) as floating hotels.  Digital is now a footnote in computer history (though we do have customers that still run legacy applications on DEC VAX hardware, in some cases buying spare parts on eBay).

There’s an old saw in the software business:

 ”God created the universe in 6 days because he didn’t have an installed base”. 

The bigger the installed base, the tougher it is to continue to innovate.  Support of old versions of hardware/software drain resources.  This is the cycle that will continue.  Some may be agile enough,  following the Wayne Gretzky philosophy of business (skate to where the puck is going to be), others will fall by the wayside.  While the Times and Forrester state:

“The substance of the report, however, is plain: cloud and mobile computing combined will rapidly improve, dislodging many incumbents in enterprise computing, and vastly empowering a few others, becoming what Forrester calls “computing cartels” that control millions of servers in data centers around the globe. These cartels, the report says, will include Amazon, Cisco Systems, Google, I.B.M., Microsoft, Oracle and a few competitors.”

I can’t help but wonder…

In 2022 what will the “Forrester business and technology outlook report for 2030″ be saying?

Will someone like me be writing, ”remember Google?”

- RTR

 

Tags: , , , , , , , ,

Commenting On The Adventures Of Process Man

31 Jan

I read a HIGHLY entertaining blog today from Stephen Porter (Zero Wait-State PLM) “Forgotten Hero-Process Man“

In this blog, Stephen describes how Batman had a distinct disadvantage to other ‘super friends’ as he had no super powers, only gadgets.  He morphs that conversation into the ‘forgotten’ superhero “Process Man” who is vital to the success of any project implementation. 

We have a long-time customer that has used our legacy product for over 15 years.  A number of years ago, they acted as an internal reference for another site.  The manager of this site asked “What would you do differently if you put CIMx in today?”.  Our customer answered [paraphrasing],

“I wouldn’t have treated it as a replacement for our old system.  That mindset really limited our use of their technology.”

I remember at the time thinking how profound a statement this was.  We had always prided ourselves in being customer centric.  In fact, our slogan when we started CIMx in 1996 was “customer driven solutions”.  Is just doing what the customer asks enough? 

By the way, this same customer, after funding an enhancement to our product that we had cautioned against, said in frustration:

“How could you let us talk you into that?”

Sounds like a job for….  PROCESS MAN!!!

Over time, we learned that the most important part of the ‘sale’ is the assessment.  It’s not about the tools, it’s about the process.  As I learned in Dale Carnegie Sales Advantage training. 

“Millions of twist drills are sold every year, but people are buying the ability to make holes.”

So let’s hear it for Process Man!  Process Man truly is the unsung hero. If you don’t understand the current and future process, you are missing the benefit of the technology you are investing in.

Companies that choose to merely automate their current process are doomed to make crap faster.

- RTR

Tags: , , , , , , , , , ,

The Problem with [PLM/ERP/MES] Integration… Is it People?

20 Jan

Since I started blogging, the ‘inspiration’ comes from two sources. 

1) Interesting things I read online or elsewhere (I am not completely paperless)…

2) Bolts of lightning

This is one of the 2nd variety.  A few of us here at CIMx were having a philosophical discussion on manufacturing process, when the dots were connected, the switch was thrown and the lightning bolt commenced. 

Is there something missing in the integration discussion?

Integrations have gotten more complex.  Technologist will continue to advance technology.  Flat file transfer becomes neutral interface tables which becomes XML and web services.  Automated error recovery.  Electronic alerts.

So why do integration projects still run overtime, over budget?  Why do the most painstaking designs still produce code that doesn’t do the job when push comes to shove?  Could it be… people?

In a previous company, I developed an integration for an automotive OEM.  This integration provided updated scheduling information for the production of stamping dies.  There was a 2″ looseleaf notebook that described the process that they used in excrutiating detail.  I codified that process and produced the integration.  Done deal….

Except it didn’t work.  After lengthy discussions and discovery, we determined that the detailed process never worked.  In their paper environment, manufacturing engineers would manually fill out the information and feed it to a clerk.  The clerk would then change the information and re-key it into the scheduling system.  The missing piece was the logic in the clerk’s head that described what the data really  meant and how the system should see it.

I’ve heard story after story in a similar vein.  There’s always an exception, always a unique case.  Computers are only as smart as the program they’re running.  People can analyze, synthesize, make exceptions, break the rules, to get the job done…  and they will

The moral of the story.  It’s not the technical connection of data you need to work on.  It’s the people side of the process….

- RTR

Tags: , , , , , , , , , , , , ,

Which Way Is The Integration Pendulum Swinging?

10 Jan

Oleg Shilovitsky writes in his blog about “PLM and the Evolution of Integration”.  His conclusion:

I think, integration will become even more important soon.

Oleg, I hope you are correct. 

I recall attending an AMR Research conference in Scottsdale, AZ not too many years ago.  There was a CIO panel, with representatives from major corporations.  During the Q&A session, one of the attendees asked, “If you have a ‘best-of-breed solution that will fulfill 90-100% of a business need, what level of functionality would you accept from your business system vendor (insert SAP, Oracle, etc.) to avoid integration?”  The panels answer? 60% – seriously, SIXTY PERCENT!!   In grade school, 60% was a failing grade!  So the translation is: 

 I would rather have a failure than an integration.

It was about the same timeframe that a senior member of AMR Research (who I will NOT identify), refered to MES as “A black hole of integration”.   Way to chill a market, there, Sparky!

That is what best-of-breed vendors face on a daily basis. 

Anyone in sales can tell you that the majority of sales opportunities that are lost are lost to “no decision”.  In the case of best-of-breed software vendors, the answer is often “the CIO says that our ERP/PLM can do all of that”.  Two years later (after the failure), it does not help OUR business AT ALL to know that we were right!   Why?  Because now the team that was so gung-ho to go paperless has been burned, and does not have the willingness, energy, or budget to start over.

The other ‘barrier’ to integration that we face is unrealistic expectations and over-design.  One recent customer, looking to integrate our offering with and existing asset management system, wrote in the requirements document that ‘all integrations have to be real-time’.  Why?  What is the business driver for real-time integration to a system that only updates itself once a day?

Integration does not have to be difficult, it just has to be effective in your business context.

The key to successful integration is not the elegance of the toolset, whether it’s “integration or federation of data”.  The key is

DOES IT DO THE JOB?

- RTR

Tags: , , , , , , , , , , , , , ,

← Older Entries

Follow

Get every new post delivered to your Inbox.

Join 115 other followers