In the high-end market, there is no room for channels/vars.
在 2010-02-07日的 20:40 -0700，Matt Warnock写道：
> On Sun, 2010-02-07 at 14:58 -0600, David E Jones wrote:
> > We're covering all sorts of ground in this thread! On the other hand,
> > if we look closely at the ground there are hints that all of this has
> > been covered before... ;)
>
> No doubt. :) I have renamed my index to "New User Guide"-- better
> describes it, more consistent with suggestions from this list, and less
> overlap with what is already there. It is a different approach from
> "Getting Started with OFBiz", and "OFBiz Documentation Index" but mine
> references both of those. It just organizes some of the stuff that PHBs
> will want to see right away, and lays out a clear plan for getting from
> here to there. Still a lot to flesh out, though, mostly finding and
> organizing the stuff already there.
>
> > Matt, I think what Chris Snow is referring to is the difficulty of
> > learning to effectively use the OFBiz framework versus learning to
> > effectively reuse the applications (both the base and specialpurpose
> > application). Based on what Chris has written in other messages he is
> > still struggling with how OFBiz is organized (ie the base applications
> > are intentionally NOT organized around business processes in order to
> > be as reusable as possible in different business processes, and
> > instead are organized around the data structures).
>
> So we're saying that "hello world" in the OFBiz framework requires
> knowing the framework, but repurposing an existing app to fill a new
> need requires 1) knowing which apps are in the toolbox, 2) knowing which
> one is the closest fit, and 3) making, testing, and deploying the
> changes. Is that about it? If so, thanks, that makes more sense to me.
>
> > In any case, there are a few reasons why the business side of OFBiz
> > (the applications) are a lot more complicated and difficult to learn
> > than the technical side of OFBiz. The basic problem is the size of
> > each, but that's over-simplifying things.
> >
> > Read Before You Write: It's not really human nature to do this, and it
> > takes a lot of patience. This is made worse because if individuals
> > have a hard time with patience, organizations are simply incapable of
> > it. The PHBs want results... and reading sure doesn't look like it's
> > producing any. What's worse is if the individual manages to produce a
> > result with a couple of dozen lines of configuration and bits of code
> > instead of a couple of thousand lines of raw, meaty, manly Java then a
> > semi-technical PHB may find it really unsatisfying to have paid for so
> > much time to get so little, not realizing that the individual just
> > save him 10-100 times what the alternative would have cost initially
> > and over its useful lifetime.
>
> This is an Organizational Behavior problem that certainly exists, but is
> by no means universal, or even in the majority. Most managers worth
> their salary know that the right tool makes all the difference. But
> they also know that there is a tradeoff between how many times you do a
> thing, and how right it needs to be. We use nail guns in construction,
> but hammers also have a purpose, even in construction.
>
> "Close enough" is OK in horseshoes and hand grenades, and in business
> processes that are not repeated often enough to make the effort of
> fine-tuning worthwhile. My wife calls the other end of the spectrum
> "analysis paralysis" and business managers can't much tolerate that,
> either.
>
> As I pointed out before, its the 80/20 rule. I don't WANT to build a
> custom tool for 80% of my business, and if I have to do that, the value
> of the whole is greatly diminished. But you are correct that PHBs do
> NEED to be able to customize the 20% that generates the profits and is
> repeated with high frequency. That 20% will differ in every business.
>
> It's like code optimization-- do you really want to unroll every loop by
> hand, and write all the code in optimized assembly for maximum speed?
> No, you get a working prototype first, then you profile it, and you
> optimize only where you must to achieve your performance goals. Much
> (most) of the time, code clarity is more important than optimization.
>
> > Scratching the Surface: A business application is not like an operating
> > system, or even a framework for building business applications (which
> > is like an operating, except the interfaces are tuned to a different
> > type of input, a less technical and more business-oriented type of
> > input). The difference is by nature there is no way to design an
> > interface adequate to represent a business application, and that is
> > what both operating systems and application frameworks are all about.
> > Unfortunately business people don't like being told that an interface
> > with a few little parameters is supposed to represent the entirety of
> > options for ANY process in their business, even "standard" ones like
> > billing or shipping. Business people don't like not be able to change
> > and tune any part of their business that they want, and if the systems
> > can't keep up then they don't get used. SAP and most ERPs out there
> > are great examples of this. They are proprietary software works and
> > you don't get the source code, and can only change what they've
> > decided it's okay to change (unless you want to rewrite something,
> > usually more than you think). Those sorts of systems don't let you get
> > below the surface, which is unfortunate because then you don't even
> > have an option to Read Before You Write.
>
> So you are saying that these systems only scratch the surface of the
> problem, because they only allow certain modifications? I wasn't fully
> clear on whether scratching the surface is a good thing, or not, from
> what you wrote here.
>
> Granted, a Business App (BA) is not an OS, and a BA is not a BA
> framework (a meta-BA, if you will). I assume OFBiz is your meta-BA, and
> you seem to be saying that there is no way to create a truly universal
> BA, because it needs to be able to be customized, and I agree. But it
> doesn't ALL need to be customized, and the part that needs customizing
> will be different in each case.
>
> Besides, if its open source, I CAN customize anything and everything--
> but that doesn't mean I want to rewrite the whole app-- only those few
> parts that are worthwhile. That is the value of HAVING an app to
> rewrite, rather than building from scratch. The beauty of OSS is that
> it offers a third option in the classic "Buy vs. Build" decision.
>
> > In other words, the way you go about adding value (via easy of reuse)
> > in a business application is very different from how you go about
> > adding value in an operating system or a business application
> > framework. With the OFBiz framework you can learn the "interface" to
> > it, but with the applications you pretty much have to deal with it
> > all. On the other hand, there are more concise "interfaces" to it,
> > like the data model and browsing things related to data model
> > elements, which is made easier with the Artifact Info and other
> > related tools in the OFBiz WebTools application.
> >
> > And how do you apply that in your business? The basic answer is you
> > don't. OFBiz is meant to adapted to businesses, not businesses to
> > OFBiz. You can certainly run it OOTB, but that's not how it's meant to
> > be used and you'll find that a painful experience. It's not going to
> > hold your hand because it was never designed to run your business.
> > Frankly, how could it be? Some systems claim they are in their
> > marketing, but that marketing isn't honest because how do they know
> > how you want to run your business? When you start trying to use those
> > systems in your business you find out pretty quick that they really
> > don't know.
>
> I think you overestimate the pain of a "good" OOTB solution. Maybe
> OFBiz isn't that, at this point. And granted, every business will
> differ. But if my 80% problem is largely solved OOTB, I have a LOT more
> time and money to throw at the 20% that NEEDS to be customized, and a
> lot more incentive to do it.
>
> Every body is different, too-- but that doesn't mean that every article
> of clothing needs to be hand-tailored to fit decently (not perfectly).
> But most any article CAN be tailored, if the need arises, and if such
> tailoring is worthwhile.
>
> > So, your best bet is to define your business and then do a gap/overlap
> > analysis with OFBiz to see what you can use, what needs to be adapted,
> > and what needs to be built to fill gaps.
>
> This is precisely where the huge learning curve is the impediment. I
> know my business, but I don't know OFBiz, so even the most basic
> gap/overlap analysis requires hiring an OFBiz expert (if I can find one)
> and then I have to educate them on my business. If I could use OFBiz
> effectively OOTB, then the gaps/overlaps would be apparent by trial and
> error, probably ranging from mild annoyances to (rarely) deal-breakers.
> But I can always continue to use existing systems and processes, until
> the deal-breaker gaps in OFBiz can be filled. In the meantime, it is
> still useful.
>
> > If you really want a tuned
> > system, like for a larger company or for a derivative work (like a
> > commercial application targeted at a certain type of company) then you
> > can define the business, design the application, and build it, and
> > save resources building it by reusing as much as possible from
> > something like OFBiz (which gets back to why OFBiz is organized like
> > it is). To do these things effectively takes some experience, and to
> > shorten the path certain tools are helpful like the HEMP approach
> > (http://www.dejc.com/home/HEMP.html).
>
> Not what I need, but others will. But the absolute number of people
> needing either of these scenarios will be much smaller, IMO, than the
> number of SMB owners.
>
> The Fortune 1000 will have big budgets for ERP, and will be hard to land
> (long buying cycle). You really need a sales army of "elephant hunters"
> to play in that space.
>
> If you envision VARs being your principal sales channel, then this
> design choice makes perfect sense. I don't see that happening myself.
> The differences from one type of company to another are probably not so
> overwhelming as you think. Why was John Sculley pulled from PepsiCo to
> run Apple? Because businesses are not that different. Apple and Pepsi
> have more in common from the marketing side than most people think-- its
> all about the brand. Sure, one item has a lifetime is seconds, the
> other in years. But the processes are largely similar, though the
> terminology may change. Is there a role for VARs? Absolutely. Is it
> the primary sales channel? I doubt it, but YMMV.
>
> VARs are always a step removed from customers and users, which makes it
> that much harder to be customer-focused. I should know-- we sell to
> distributors, which sell to retailers, which sell to users. If I didn't
> go out of my way to talk to end users, I'd NEVER know what they think of
> our products. I could tell you some war stories...
>
> > Stepping back a little... there is a bigger trick... and that is how
> > many people believe what I wrote above Read Before You Write and
> > Scratching the Surface? Well, not many. For those that do understand
> > and agree OFBiz is great (could be better, lots better, because even
> > many people involved with OFBiz don't believe or don't understand
> > those two ideas and as the number of contributors increases that
> > painful fact becomes more apparent). For those who don't understand or
> > don't agree, they are destined to a life of making things painful for
> > them and others they work with, whether they attempt to use OFBiz
> > (probably won't last long) or whether they choose a likely painful
> > commercial route filled with reasons to spend more and more money on
> > more and more different software.
> >
> > -David
>
> This really boils down to a basic marketing issue: who is your customer,
> and what do they really need? If you really meet that need effectively,
> delivering solid value, you will be successful beyond your ability to
> expand and serve. How do you segment the market? By revenues? By
> industry? By employees? What are your sales channels? Direct? Through
> VARs or consultants? What are your customers' real needs and how well
> do you meet them? In the venture capital community, we sometimes talk
> about "a solution in search of a problem." Companies (or non-profits)
> that don't know what their customers really need will always struggle.
>
> If this is indeed a "missionary sale", in that you have to sell people
> on a value proposition that they can't really see, or won't see for
> months or years, then you do have an uphill battle, no question.
> Thinking that they are stupid won't help. Suffice it to say that I
> don't think it absolutely HAS to be that way.
>
> In my management experience, if I'm not getting the sales results I
> want, I try to re-examine what I'm doing, and I usually find that the
> reasons are both apparent and solvable. A better mousetrap is often in
> the eye of the beholder-- a completely customizable mousetrap might not
> be the overwhelming marketing advantage, if you want to be catching mice
> like, yesterday. (And who doesn't?) But if you give me a better
> mousetrap today, and it *immediately* solves 80% (or even 60% or 40%) of
> my mouse problem, who do you think I'll call for the more intractable
> part of the problem?
>
> When I get entrenched in a particular view, my wife sometimes asks me:
> "do you want to be right, or do you want to be happy?" Or as Dr. Phil
> would say, "How's that working for you?" Often the only difference
> between a martyr and a hero is-- well, the hero actually WON the battle
> in question. If you find yourself in an uphill fight to sell a solution
> to someone else's problem, maybe it isn't (yet) quite the solution it
> needs to be. Not that it isn't great-- it just may need a bit of work
> yet to really break loose.
>
> You've brought OFBiz this far (and that is a LONG bloody way), so I
> figure that you are a pragmatist and a problem-solver at heart. And I
> think you have the groundwork laid to blow this market wide open,
> building a much larger, more committed, and more wealthy community, if
> you can make the value proposition more palatable to average SMB
> leaders, who I think are often smarter than you sometimes give them
> credit for.
>
> Not all PHBs got there under the Peter Principle. Especially in the SMB
> sector, which is where I see the biggest potential for OFBiz. ;)
>
> http://en.wikipedia.org/wiki/Peter_Principle
>
> And BTW, I'd still like to take you to lunch next time you are in town.
> Do you know when yet? :)
>
> >
> >
> > On Feb 7, 2010, at 10:45 AM, Matt Warnock wrote:
> >
> > > On Sun, 2010-02-07 at 08:30 +0000, Christopher Snow wrote:
> > >> Matt, what was the 300 - 400 hours for?
> > >
> > > It was Milind Parikh's estimate of the learning curve, except I
> > > misquoted. He said people should be "expected" to spend 200-400 hours
> > > to "understand OFBiz".
> > >
> > >> I think that time would give
> > >> you the capability to develop a standalone solution. If you want to use
> > >> existing functionality (order mgt, invoicing, shipping, mfg, workeffort,
> > >> etc) you need a lot more time depending on which functionality you use.
> > >
> > > I'm not sure I understand this. After 300-400 hours you can develop
> > > standalone apps, but using existing functionality takes longer? I would
> > > think it was the other way around?
> > >
> > >> I've been using ofbiz pretty heavily for nearly a year now, and have a
> > >> 'good' understanding of developing solutions. In terms of the
> > >> components, I am only really starting to get a deep understanding of how
> > >> workefforts work. If fact some discussions I've had on the ML suggest
> > >> that it may not be possible to know all of ofbiz at all. Instead you
> > >> have to know how to find the answers to the areas you are trying to
> > >> implement. However to know how to get the answers, you need to know the
> > >> questions to ask. For this you need a good understanding of the overall
> > >> system, for which there is no documentation except the universal data
> > >> models.
> > >
> > > I can take any Linux (or BSD) distribution off the shelf, spend a
> > > half-hour installing it, and immediately get SOME useful work done. It
> > > may not do everything I want, but OOTB, it does the basics. And OOTB, I
> > > can use it well enough to at least evaluate how well it meets my general
> > > needs.
> > >
> > > I can then work on tuning the system to my specific needs, or use it as
> > > a platform to develop custom apps. I don't need to understand all of
> > > the kernel (say the schedule or VM code) to get my job done, let alone
> > > the whole system. If I need to write a new driver, filesystem, text
> > > filter, or whatever, I take an existing one as a template or example,
> > > and I write another that can be plugged in. And you're right, I doubt
> > > anyone knows it all, and that's OK.
> > >
> > > By the same token, IMO, you should not have to understand all of OFBiz
> > > to either 1) use it productively, or 2) write apps (or other plugin
> > > code) for it. If that is not the case, then the system design and
> > > modularization needs improvement.
> > >
> > > And that is exactly why (I think) your work on framework independence
> > > and attention to dependencies is really important.
> > >
> > > --
> > > Matt Warnock <mwarn...@ridgecrestherbals.com>
> > > RidgeCrest Herbals, Inc.
> > >
>
>
