 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 7/31/2015 7:47 PM, Orchid Win7 v1 wrote:
>
> Selling "support" also works. Provided you have the staff to actually
> deliver support.
>
The sector I work in, often supply the software customisation at what
they hope is break even prices. To get the support contract.
> Or just a licence to download any and all new versions that get put out
> in the next X months. Keep paying if you want new stuff.
>
> Or paying to have a customised version of the product. (But that's sort
> of tantamount to saying "our product is so hard to set up, you need to
> pay us to do it for you". Not a great thing to say!)
>
Shhh!
> Or hell, even paying for the development of specific features that you
> particularly need. The trouble with this one is that
>
> * Usually there's only one or two specific features a given customer
> needs. Once those are done, no revenue stream.
Not necessarily. SAP helped Shell configure their system for offshore
logistics. Then sold the solution to other oil companies as an Industry
Solution. They did the same with Rolls Royce Aero-systems and created an
expensive IS-Aero module. Which they sell to aircraft companies. (That
is the system that will be able to tell the investigators of the MH370
crash. Which aeroplane the flaperon came from.)
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> On 31/07/2015 09:56 AM, scott wrote:
> >> I've read scuttlebutt about M$ moving Windows to a SaaS model, but I
> >> fail to
> >> understand how this could possibly work.
> >
> > Locally you'd have an OS that was stripped down to just run Remote
> > Desktop (or equivalent) and interface with your hardware. When you
> > logged on it would start a remote desktop session with an MS VM
> > somewhere. *Assuming internet speeds were fast enough* you wouldn't
> > notice the difference to running full windows locally.
>
> The more I look at the IT world, the more cyclic it seems to be.
>
> There was a time when you bought the biggest, most powerful mainframe
> that money could buy, and all the users sat at dumb terminals logged in
> to the giant monster in the middle.
>
> And then everybody said "hey, putting a single desktop at each person's
> desk means you can more easily add and remove computer power depending
> on staffing levels, equip different people with different versions of
> software, etc."
>
> And now everybody's like "hey, it's a pain to manage multiple individual
> desktops. Let's virtualise everything to get a bigger return on
> investment..."
>
> And so the industry continues to alternate between centralised and
> decentralised. Because, frankly, each has different pros and cons; it's
> just that every decade or so people forget the pros of one and forget
> the cons of the other.
>
> > The benefits are obvious (a machine that has all your files and looks
> > the same no matter where you log on, an almost limitless supply of CPU
> > power and RAM if you wanted to do CPU intenstive tasks, automatic
> > backups for everyone, etc)
>
> I think you mean "we can give you less and less CPU and RAM while still
> charging the same amount of money for it, so you will continually have
> to give us more money or suffer horrendously unusable system response".
>
> And then of course, you have the problem that each morning, you log into
> your desktop, and there's a 50% probability that the software will have
> changed, and you can't prevent it changing. Already we see every time
> Facebook changes the colour of a button, somebody creates a page
> entitled "if one million users Like this page, Facebook will turn the
> button colour back to how it was before". [Erm, no they won't honey.]
> Imagine if every day, all your software could be deleted and replaced
> with something else that you didn't ask for or want.
>
> To say nothing of the privacy and confidentiality issues of having
> Microsoft have access to every file you ever create. (I doubt too many
> corporate types would like having their propriety data on a hostile 3rd
> party server.)
>
> > Their big problem will be the medium-large corporations that take
> > months, if not years to test and roll out major software updates. There
> > is no way they would accept the possibility of one day their entire
> > company coming to a halt with millions of pounds lost due to an MS
> > "update" that has broken something somewhere within their business. Also
> > a lot of systems are not connected to the internet for various reasons,
> > how would they work?
>
> They also have a problem with SOHO setups where people wouldn't know
> what "computer security" is if it hit them in the face.
>
> Why no, I'm not bitter. Why do you ask?
The difference between a company with a gigantic mainframe that all the
employees log into from a single campus and the idea of Windows as a Service, is
a pretty big one, IMHO.
Now we have people whose office is the world. They take their computers into
the field where they sometimes won't have internet access for days on end, and
when they do, it's in some third world country over a satellite feed that has
limited bandwidth.
Then too, at what point do you think that the governments of the world will
become comfortable with their internal communications being stored -- even
temporarily -- in the buffer of someone else's computers? Personally, I think
they'll go back to using typewriters first, but realistically, they'll probably
just switch to linux.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
> Selling "support" also works. Provided you have the staff to actually
> deliver support.
The problem with this is that if you're selling support, your product is
poorly designed and difficult to use.
If you're a software company that depends on support and training as
bottom-line revenue figures, you're doing software wrong IMHO.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/08/2015 12:09 AM, Jim Henderson wrote:
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
Heh. Well there is that... ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2015-07-31 19:09, Jim Henderson a écrit :
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
>
You're saying a oil-rig management system, or an MRI control system
shouldn't require training?
I agree that if you're selling 3D-tictactoe-as-a-Service, and expect
people to call you for support, you may have a problem, but complex
software such as ERPs, or even industry-grade CAD systems _should_
require some level of training to install and operate properly.
> Jim
>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.08.2015 um 01:09 schrieb Jim Henderson:
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
Support := help with operating the software in conditions not
anticipated during the design.
Nothing wrong with that in my book, provided the company isn't shifting
costs from the design phase to the support phase.
Sample case: A big company I worked for some day realized that they were
growing out of the version control system they were using; apparently
the system was designed (and purchased) for a much smaller number of
projects and consequently a much smaller number of changes than what was
by now happening at that company, and was now running out of IDs for the
changes. The software company provided support by shipping a
custom-tailored build of the software using larger data fields for those
IDs.
Also, there are types of software - most notably any non-trivial
business software - where unanticipated operating conditions are the
norm; no two companies of any significant size have the same business
processes. Therefore, standard business software is designed to be
adapted for each individual customer, but this adaptation process is
non-trivial because of the flexibility the software offers.
Some software companies seem to be able to provide this level of support
free of charge, but I have no problem with software companies covering
the costs for this type of post-sale development by selling service
agreements.
But of course if you define support := user-driven on-demand training of
individual end users in how the software is supposed to work, then yes,
if that's your business model then you're certainly doing something wrong.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2015 12:09 AM, Jim Henderson wrote:
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
>
To add to Francois and Clipa’s comments (I hope I got the apostrophe right).
ERP software is initially configured with the help of the customer’s
management and key users. They know what they want and outline their
requirements. By the time the blueprint is designed, and implemented.
The customer knowns more about how the software works and often redefine
their requirements. This can extend the implementation to the extent it
will never be finished. (At BASF the German branch took 10 years on a
pilot project and they were still not finished.) So there is generally a
“Freeze” where there are no more changes allowed. After the “Go Live”
the support company will make the changes wanted. This can be quite
extensive.
These programs are quite complex and it is not normal for the company to
do them as they generally do not have the expertise. If the company is
regulated by, say the FDA, Financial authorities, Nuclear regulators
etc. It has to be done by an authorised external company.
User support is almost a freebie.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Aug 2015 10:37:20 -0400, Francois Labreque wrote:
> Le 2015-07-31 19:09, Jim Henderson a écrit :
>> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>>
>>> Selling "support" also works. Provided you have the staff to actually
>>> deliver support.
>>
>> The problem with this is that if you're selling support, your product
>> is poorly designed and difficult to use.
>>
>> If you're a software company that depends on support and training as
>> bottom-line revenue figures, you're doing software wrong IMHO.
>>
>>
> You're saying a oil-rig management system, or an MRI control system
> shouldn't require training?
Of course not. There are things relating to the system that are not
about the system itself.
What I am saying is that if your UI is so complex that it needs a guide
or a training class, then your UI is not properly designed.
> I agree that if you're selling 3D-tictactoe-as-a-Service, and expect
> people to call you for support, you may have a problem, but complex
> software such as ERPs, or even industry-grade CAD systems _should_
> require some level of training to install and operate properly.
No, training is required for the job. In order to use a CAD system to
design aircraft properly, for example, you need to understand aircraft
design.
Using the UI should be intuitive to someone with the necessary skills.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Aug 2015 18:21:26 +0200, clipka wrote:
> Support := help with operating the software in conditions not
> anticipated during the design.
In software these days, design tends to follow implementation - which is
backwards.
That's what leads to a lot of broken UIs. No design before
implementation - the design comes with the implementation, and it follows
the implementation rather than having a UX plan before the implementation
starts.
> Nothing wrong with that in my book, provided the company isn't shifting
> costs from the design phase to the support phase.
Indeed, that's the problem I'm talking about - but with the added bit of
"pay us to tell you how to use it properly".
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Aug 2015 19:29:40 +0100, Stephen wrote:
> By the time the blueprint is designed, and implemented. The customer
> knowns more about how the software works and often redefine their
> requirements. This can extend the implementation to the extent it will
> never be finished.
Very true.
Two words you mention at the start, though, are not often enough included
in software development: "blueprint" and "design".
Specifically, user interaction design.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
