I don't think that's the case. I think the Single Barrel actually refers to the fact that it wasn't transferred to a second barrel:) For instance, look at the The Balvenie DoubleWood as one counter example of single-malt, multiple barrel.
The screw-top does provide a plastic seal. If by "plastic" you mean foam corks, then no they do not provide an air-tight seal. In fact a lot of R&D effort is currently going oni to better understand the level of oxygen transfer that helps the wine age, as it is already known that no oxygen transfer harms the aging process. While this is good for cheaper wines and may help fruitier wines, your premium wines that are put in a bottle and expected to be aged need this oxygen transfer to reach their potential. The largest synthetic cork manufacturer is leading research and symposiums on controlled oxygen transfer (which makes sense, much easier to control density in a manufacturing process than in a tree growing/skinning process).
Screw-caps are actually the cheapest solution on the market, synthetic and natural corks are priced similarly, depending on the quality of the closure (premium natural/synthetic to less-than-premium synthetics and the corks that are mostly cork shavings).
Is it me or did you just complain about a bunch of things that windows CE does poorly but that the competition doesn't do at all (mixed with a few things that the competition does better)?
Ive worked with Windows CE for a while, as well as a number of other mobile OSs. I agree with most of your list and Windows CE likely annoys me to a much greater level than you as a user. Some of the problems you listed are definitely CE issues, but some are not. When a vendor decides to put CE on a device they compile a specific version for their device and determine what to include. We are looking at a device with Windows CE 6 that has.Net 3 and IE6 already built in, as well as a number of the more annoying CE "feature" applications removed. So while some of the blame is definitely on MS, a good portion also needs to rest directly on the vendors AND the telephone providers (you know, the same ones that don't allow you to upload applications over a cable and demand you do a wireless data transfer despite the fact that the device manufacturer specifically built in the capability).
I'm left wondering what kind of companies you guys work for that you believe complexity only comes in algorithmic flavor.
I provide comments for the following: Class level - this is the general idea of the class as a comment so you don't have to grok the entire chunk of code at once Method level - this is either for doc builders or like the class level, to get a general idea of how something works without reading the next 500 lines Complexity - Whether it is algorithmic complexity, business rule complexity, whatever - if it is not immediately obvious _WHY_ I am doing something, it gets a comment
So far most of these comments have been along the lines of "I don't comment because I make readable self-documenting code". Great, but when I come back in two years to maintain your code and I am trying to figure out why you did something a certain way - a comment with a little information on your intent or why you programmed your logic in that manner goes a long way
Self documenting names are great, but assuming that you don't also need commenting because of your naming technique is a bad assumption to make. The fact that code changes are done without accompanying comment changes does not invalidate the usefulness of comments, it invalidates the level of work you think your doing.
I would disagree. Planning and Design is every developers responsibility. Whichever piece your responsible for (from the whole thing down to one small chunk), you spend time planning it before jumping in to put code on the screen.
Even if you have smoeone who works full-time just on documentation, you should be providing them with at least notes and good comments, if you don't have a documentation person than don't expect your Mom to come in and do it for you later.
Version Control is iffy, depends on your environment. Some places won't let certain levels of developers touch version control, some places only have one developer and versioning isn't even setup yet. in the second case it should be setup and used, in the first case someone else has the responsibility.
Self-testing is critical in many environmants. Small development groups may not have dedicated test people, frenzied environments may have test people, but part of the testing should include "Does it work the Way I, as the developer, expect it to?". In a frenzied environment you don't often get a chance to go back and fix these things, test early and test often.
By spreading the resources into separate departments you may see some short-term gains from members focusing on their new departments, but in the long term this method is going to cost you. Without a cohesive strategy your going to be leaving each technical person to build their own solutions, follow their own standards (if they have any), and operate against one another when their specific departments do not agree on a solution. Your department specific people will communicate less with one another than with their respective departments, causing a lot of redundancy and friction, especially when several representatives have their hands in the same multi-department system.
I am an IT developer. I attend kaizen events, initiated a long term IT strategy to match the business needs by interviewing each department director combined with the feedback I receive regularly from people who work on the production floor, and I communicate solid plans (and results) to people involved in any systems change from the lowest to the highest levels.
I am an IT developer, yet I led a server migration late last year that involved the ERP system, legacy warehouse system, and multiple support systems that would not only be getting OS upgrades, but also SQL Server upgrades and a complete rename to the new naming structure. Everyone, from the CEO down to the associates running the equipment, knew that the upgrade was taking place, how it would affect their daily lives, and had seen a list of the affected systems in order to provide us any information they felt was missing. We executed the actual migration with two weeks of pre-work and testing and used 2 of our planned 3 day outage (company was closed for Christmas week). We had zero downtime when everyone came back on January 2nd and finance only found two excel docs that misbehaved, a 10 minute fix and no lost time (they wouldn't have been critical until late in the year).
I concentrate on my job and that job is to provide tools or technical opinions to help make the current operations more efficient or reduce the overhead necessary to operate as a company. I think it is my duty to know how the company operates at all levels, rather than assuming that an executive is always able to make a decision that provides benefit, instead of detriment, to the process.
The biggest failures I have seen is non-technical people making technical decisions or assuming that because they once built a computer at home, programmed macros in excel, or led a project with a heavy IT element, they have the knowledge and expertise to not only do my job better than me but to provide technical review on prospective software purchases or installations. These are the people that lead projects or make decisions that force IT to work on non-value added activities or to accelerate timelines into the high-risk territory, simply because the company ends up listening to the barely technical instead of someone that has a solid technical background.
I agree that IT is suffering a problem. That problem is the business listening to the barely technical above, who think that the ability to do one thing has given them the knowledge and experience to override someone that has done that one thing hundreds of times and understands why "making it work" is not the goal. I don't care if you can make a *nix server work at the end of the day. If you couldn't follow a standard process, ensure the documentation has been added to allow the next person that comes along to work on it competently, ensure the backups have been scheduled appropriately, ensure the extra services on the system have been battened down, setup the monitoring system to monitor everything down to the chassis fans, etc then you have hurt the company, not helped. Making it work is the easy part, the hard part is making it work for the long term and ensuring that the longest part of it's lifetime, maintenance, can run as smoothly and efficiently as possible. When the barely technical start making technical decisions the project may get done a l
And I am an IT person with a CS degree that worked as a historian and i/o integrator, industrial software developer, and most recently have been working on a project to integrate equipment w/ layer 4 scheduling data.
Most of the places I have done work for I have seen at least a small number of HMIs that were running on Windows (InTouch, ProcessBook, RsView, etc). I agree that kiosks can be built running off of a read-only image, etc but that takes a great deal of effort, especially for a system that likely cannot be imaged for easy replacement. A better solution would be to install the antivirus and tell it which files need to be ignored. If this continues to cause problems for the system then it is likely you are running more than an HMI on it. Disconnect those serial rocket boards, install some nice serial to ethernet switches, and put your I/O on a server instead of a PC where anyone could walk by and mess with it. Just because you can connect live I/O to a PC does not make it a good idea. If your HMI is overloading the PC when anti-virus is installed, your doing it wrong.
An even better solution would be to stop using PCs entirely. There are a lot of really good CE-based HMIs out there that are built specifically to run HMI software.
And rather than closing with a broad generalization as you have done, here is a more specific comment from my own experience: It's that damned subset of engineers that insist only on hardware requirements and install equipment without any regard for how it needs to interact (or in many cases how it will communicate at all) with data systems and other infrastructure, regardless of the consequences. The good engineers take a step back and determine the true needs of the equipment and process, requiring vendors to provide them with solutions for the larger scope, not just something that can be slapped in and called working.
My last gaming rig I went with an Antec P180 and an Enermax Silencer 2 PSU. XP 3400-ish, 2GB, 7800GTX OC (getting a bit dated now). It's not silent but you can't even hear it next to the $150 linux box next to it. If it's the only thing running there is a very quiet sound of air moving in the background. I found the case and the PSU made the biggest sound difference, everything else in the box can either be turned down (antec 3-speed fans) or replaced cheaply (quieter 40mm fan $8, quieter CPU fan $12). The other main noise point I used to have was the HDD, but most newer drives use something like fluid dynamic bearings and the P180 has silicone pads around just about everything to kill vibrations.
I'm not sure what kind of business your outlining there, but I know in the manufacturing world you would be asking for trouble. If nothing else you would need a pretty large pipe to push all the machine control data to the internet at sub-second rates, so they could be operated on by a internet-based software logic engine that looks up information from the internet-based formula management database, which then writes back PLC-specific data to the plant PLC and HMI to tell the operator they cannot use that part in their current order...
I agree that there are a number of business office tasks that could be easily ported to other systems if made agnostic and many of those could possibly moved to an ASP, but I don't see the bandwidth or applications to move manufacturing floors to an ASP, much less convert what is primarily a Windows environment (ie, the majority of manufacturing software, the rest is VMS, Solaris, and others that are slowly fading out) to run on a secondary operating system.
And from what I understand from a friend that worked at MySpace not too long ago, the server architecture is non-existent. Basically tons of servers pressed into service as and when needed with no plans, documentation, etc. One story was how a server had failed that was believed to be providing critical data replication services to and from other servers. The job was to determine which of the other hundreds of servers were expecting data from this server, which thought they were supplying data to this server, and what else might have been on it. Then to re-create it.
If thats their systems administration and design I'd hate to see how painful the help desk side is...
Personally I would forget most of the encryption and delivery schemes already mentioned above. None of them account for the security at the end-users site. Even NDA's do not strengthen the end-users security if it has holes (or is non-existent).
Using either the data export or a copy of the database you are exporting, create a series of scripts to junk the data. For the SSN field have it replace all of the digits in the SSN with randomized numbers. Swap values between each recor and a randomly chosen record for the first name and last name fields (independantly, so that no one record has the original first and last name together anymore). Do the same random number digit replace on all street fields. Do the random record swap on all city and state fields. Continue with whatever else you have.
This may take longer than just faking up some data, but it ensures they have real values in data fields for testing, the format of the data is exactly what your real data is, and it should be absolutely useless in the event of a security breach between the two sites or at their site.
Now send burn it to a disc and set it via registered mail to ensure it gets there.
RoadRunner started doing this a few months ago in my area. Luckily they made an opt-out option very accessible as part of the search page. I'm against the whole idea of replacing non-existent domains with ISP generated content, but if they're going to do it then having a painless opt-out option should be mandatory.
It seems as if your decided on CS for a degree. While many people have posted on the additional experiences and opportunities that you could have by going to a school that will likely focus more heavily on required classes from outside your chosen degree path, I have yet to see any posts on another important factor: How broad is their CS program?
I went to a college that had a smaller CS program, but it was decently broad in nature. By the time I got to the 400-level classes there were 15 or less people in each class, but the classes also represented a great number of sub-fields in CS; from advanced classes in AI, Distributed Computing, and Signal Processing to a number of more esoteric courses they were trying out in web and 3D modeling. Not to mention the ability to pick up business classes or additional math or science classes (or even Liberal Arts courses) that could allow you to pick up a minor or further explore another interest.
If your primary goal is a CS degree, I agree that it rarely matters to an interviewer where you received that degree (though it does matter on occasion). However, the breadth of courses available from the institution and the number of classes they will _allow_ you to take from your major (as opposed to required credits from other branches and required elective credits from other branches) are going to have an impact on the level of knowledge you attain and the number of sub-fields you will get to explore. Additionally, you should look into how much the school supports internships. One of the things that helped me best during my college education was the fact that I was working for pay on real projects, which then gave me a different perspective on the course material.
Also, if you are considering a highly recommended liberal arts school and a highly recommended tech school, why not look at one or two state colleges that have good CS departments? The price range (even out of state) may be in the same range you are looking at for that liberal arts college, the fact that it is a state school will likely have brought in students for a wide variety of degrees, but (if you use CS program quality as criteria) there will also be a greater breadth of CS classes available, allowing you to learn about multiple sub-fields to better determine where you would like to go in CS.
In cases where buying and selling of power is happening at the plant level, it is not going to be the equipment operator that is buying and selling power. And the person selling power does not need access to SCADA systems, thats what the telephone is for and why they have operators at plants to run the equipment. if somewhere there is a plant that is small enough that one person is both buying and selling power AND running the equipment, I'm betting they barely have an internet connection, much less the money to keep up on annual maintenance for the equipment, etc. In the power plants I have worked in (mostly gas turbine, only one nuclear), there was not any type of internet access from PC's on the controls network. For the most part these systems only ran some form of HMI software (WW, RS, WESstation, whatever) and occasionally something like MS Word or Excel for shift pass-down notes. Sure they had a browser (on the Windows systems) but it wouldn't get them anywhere because there was only one system that had any level of access to both the business intranet and the controls systems. This system (data historian) could only receive communications from the controls side (which had interface software that knew how to contact the historian) and communicates in a proprietary protocol.
Now, as far as the corporate office is concerned, pencil and paper are good enough to keep track of which plants are running which generators, which plants have which generators down for minors or majors, and which plants have generators idling (running with no load at very low levels, not on the grid - cheaper to idle them in most cases then to shut them down). However, in the case of at least one company I worked for, their historian had an interface that pushed data back to a corporate historian, then some reports and so on would run at corporate that drew data from the corporate historian and reported machine statuses, load level, etc up to the last few seconds. This is again using the same proprietary protocol (or heck, maybe a different one).
I don't know what power company this article is about, only that I didn't work there and didn't do any type of integration for them. Whoever setup their infrastructure hopefully learned a lesson and will do it right next time.
Sorry, this caught my eye:
it's not likely you'll find a bunch of stuff in a store that you didn't put there I threw together a small app to run on our warehouse guns (MX6's running windows CE) over the course of two days in order to do year end inventory. The idea was that the system had to ignore what it thought was in inventory and allow entry of anything that the teams found while blind scanning the entire inventory. And yes, we found many, many things we hadn't put there (several that the system had said shipped a couple years before in fact). If your cycle counting or inventory application doesn't allow you to scan items that are in the wrong location, or are no longer in the building, then your missing half your variances during a cycle count (the stuff thats there and shouldn't be).
First, I'm not sure if your talking ASP or ASP.Net, but either way the vast majority of your comment can be shortened to: There are lots of PHP packages out there. People think they are safe because they are not MS. PHP packages should be re-written in ASP. PHP breaks due to updates but ASP updates better, therefore ASP is a better choice. PHP isn't inherently insecure, it's the packages.
Your entire statement boils down to this logic: 1) There are a lot of insecure Packages in PHP 3) It's not an insecurity in PHP, it's an insecurity in the packages 2) ASP updates better than PHP
Your comparing apples (ASP) to oranges (PHP Packages). I have no experience how well or poorly the security of packages in PHP perform against the security of packages in ASP.Net, we would have to pick a large pool of them to find out. And just because Windows Updates makes updates available for ASP.Net does not mean that people actually are that willing to reboot their web farms for every update that appears. Your saying the problem is bad coding and that ASP solves it, I would beg to differ.
And here is my anecdotal comment: I have answered thousands of ASP questions (ASP used to be my primary web 'language') as well as written/re-written many sites and over time I have seen a lot of site examples and snippets that would leave a page wide open or in a position to break on regular occasions (or just plain didn't work). On the other hand I have worked with several PHP packages that were solidly put together and worked against a range of PHP versions. PHP must be better because I haven't personally seen anywhere near as many errors in coding as I have in ASP. None of the first several thousand ASP posts would work at all against the next version of the language (ASP 3 => ASP.Net) and needed to be rewritten from scratch, but most or all of the packages I used with PHP 4 worked just fine with PHP 5.
Well, if your gaming on a dell, then I can believe the low price and disbelief. My last price list looked more like:
Case: $125 PSU: $125 Mobo: $125 CPU: don't recall, I think $300-ish Ram: $100-$200 HDD: $100 GPU: $500 Mouse: $50 (x2, I've worn at least one out since I built this system, maybe two) 22" monitor: $300 (recent purchase, 2ms LG)
Granted I plan on reusing the case and PSU on the next rev of this system, which is why I went with solid ones, and the only reason I bought a $500 graphics card was because I never had before (I usually buy the bast card from 9 months ago, that time I bought the best card). This investment gave me a box that stayed near enough to the higher end for a while and still, two years later, plays everything I want very well. I'll probably be looking at an upgrade later this year, at which point the Mobo, graphics, and RAM will migrate to either my wife's box or the PVR. Sorry, I just couldn't see getting the same performance from a Dell.
Master pages were actually created in response to the fact that doing includes or "components" (to keep your header and footer logic/presentation centralized in one file) was somewhat painful. It's once again hit the magic MS bar of implementing an idea so far, but no farther. If you look behind the scenes at a number of PHP packages (phpBB3 comes to mind) you will see a full (real) templating system built-in that goes beyond the basic "surround the content with some stuff" that master pages gives you. At the other end of the spectrum you have simple file includes for headers and footers that give you exactly the same capabilities as Master Pages.
If anything, Master Pages to me were another example of ASP.Net going the wrong way. For all of the arguments about separation of logic and presentation, I don't thin the ASP.Net architecture quite gets how the web works and what layer is supposed to be separated. While it is possible to have good seperation between a data abstraction layer, logic, and presentation, what you often get is a mish-mash of the three as ASP.Net attempts to make components available to do the work for you. And the further you wander towards dynamic content and good seperation, the more painful it becomes. Just look at the validator controls and the fact that they have to do extra work to figure out what client0-side control will be called when they are rendered and renamed. ASP.Net starts with the presentation aspect and everything else derives from that. Languages like PHP or ASP 3 may not force you to use data abstraction or other good methods, but it's the same as saying your starting a race at the starting line (PHP) or starting the race 5 miles back and facing the wrong direction (ASP.Net) but man you have some nice shoes to run in.
At least you threw in the 'competitors' comment this time, so I'll have to extend my normal argument.
Show me the Open Source industrial data historian and HMI/QA suite. The tool suite must have:
HMI software
a logic engine to work with real-time process data using programmable objects
additional components or packages to track downtime, performance, utilization/efficiency, order management, recipe management, traceability
SPC and SQC tools
Be accessible for import into some basic tools like spreadsheet tools
Be accessible from a database server/reporting server
Have drivers for: Start With This listand then finish this one
Whoops, we need a reporting server too, so add that to the list also.
Could I write all of this software? Yep, with some help from other software types and some EE's and licenses from just about every company listed on the above websites to allow me to write drivers that talk their proprietary languages (which I doubt they would allow to be Open Sourced). However the cost would end up being much greater, especially in this vertical market, The 'competitors' you mention would need to each be paying for developers and EEs for the rest of their lives in order to keep their software tools up to market standards, continue to port them to new systems as they come out, etc. In the far off future it might be worth it, provided licensing fees to AB, Siemens, etc don't hurt too badly. The real question is how many manufacturing companies (not even real competitors) band together to bring the price down and how do you justify double or tripling their licensing costs for the at least the first 3-5 years (they're paying to continue to use what they have and for development of new software) just to barely do less than break even from then out? Assuming you get a good following of consultants to do training and installs for your product, how do you provide them with support on top of the development?
I could continue, but the point is that every time I see someone make a generalized comment about companies banding together to replace their software with Open Source, I notice that the entire manufacturing segment is left out of the equation. I'm not saying it would be impossible or that there aren't some tools out there already, only that Open Source isn't even close to being on the radar in this area right now at the level of paid-for alternatives, and would require companies to throw significant money away in order to catch up quickly while still leaving them dealing with the equivalent of thousands of broadcom drivers.
That depends on what you mean by "utilities". If your talking about corporate offices and so on, then yes, i'm sure they are hooked up to the net the same way most large businesses are. If you mean the individual plants, well, thats different.
The last power company I worked for in the the US (Southeastern US) was most definitely not setup this way. While it was possible to remotely connect into various plants, the deepest you could go was to connect to the Data Historian that had limited connectivity over to the controls network to receive data from the equipment for storage. Not that there was direct access to the plant, first you had to VPN into the corporate servers then from there you had to know exactly what you were looking for (since the handy directory of historian server names was under pass and lock elsewhere) to connect to the server at one of the plants. The plants were setup with the controls systems completely separate from the intranet at the plant (except for the one connection to the historian). PCs, on the other hand, were setup on the corporate business VLAN and completely separate from the controls systems, so no other variables are introduced.
In order to do anything to affect the controls you would have to take over the data historian, which itself had very limited connectivity (basically enough to pass data on to the corporate historian and send weekly data backups to a corporate server). Then you would have to reverse engineer the proprietary communications protocol between the server and each of the software interfaces on the controls side. At that point, provided you found some method of causing a buffer overflow or some other type of similar vulnerability, you would have access to a software interface that had a read only connection to either PLCs or another intermediary piece of software. Provided you could then perform some piece of magic (not counting the one involved in decoding the communications protocol and finding a hole in it), you would have the ability to read any tag value from the equipment that interface was connected to...err, and you still wouldn't be able to control anything. And those interfaces are able to handle subsecond poll rates on thousands of values, so taking them out by trying to DOS them from the Historian would be difficult and, since they aren't controlling anything, fairly useless.
I'm not sure the idea of splitting the IT responsibilities into other departments is insane (hold with me a moment). Consider the current situation of an IT department that is a separate department, usually with their own goals, budget, etc. This department is notable for not always getting new PCs as fast as they are wanted, for not implementing software changes immediately when requested, and for demanding additional money when deploying technologies like video conferencing so they can upgrade the internet connection or some other foolishness. Oh, and they always act like they are busy, but we all know the systems hardly have problems.
Unfortunately the suggested solution, of splitting IT into the surrounding departments, is going to look like a good idea to many director level people. It will (in their minds) ensure immediate service for new equipment, allow a higher level of control over the purchase of items they think are unrelated, and allow them to have changes made to software at a higher level of priority. To the outside manager or director, they generally only see what we are not supplying, not what we are. If we are good at our jobs, but have poor systems, they don't generally realize just how bad things are because we are keeping the system limping along. A lot of our expenditures are due to reasons they just don't understand. If we buy a 48 port managed switch with fibre but were rolled under one of these departments, it could very easily turn into a refurbed 48 port hub off ebay, since they both have lots of connections and thats all you really need.
What about change control? They don't see it. Time for testing? That will get reduced further. Developing in test environments? But those are good machines, they should be used for something important. Oh, and why do you need fancy development tools? Joe down the way made an application to do that in 45 minutes using MS Access, but it takes days in this fancy technology, we'll just use MS Access instead.
The whole idea of splitting IT up into several departments is like a startup company (non-tech) in reverse. Money will go to IT-related resources last, it will be in no one's interest to spend the time, resources, or money to ensure there is a strong infrastructure capable of growth, in house software development will be on-the-fly and likely based on technologies like MS Access. On top of that, larger initiatives like data warehousing, global data management will be left to whoever wants to pay for the whiz-bang consultant to come in and do it their way. Backups, email, directory services, all of this will end up on someone's plate who will forever be trying to drop it off on someone else.
I realize that the author of that article was likely thinking that IT resources would not need to deal with most of these things in the future, and for that I can assume he has not worked in an IT environment in quite a while. While technologies are available to streamline our jobs and allow us to grow the department(s) more slowly that in the past, splitting the department so that no one has these responsibilities is going to have one positive thing going for it: The consultants that come in to clean up the mess after the takeover are going to be set for a good long time.
While NTFS would have still been used behind the scenes, you the user would have been interacting with WinFS as your filesystem. It was intended for every file and allowed for a greater level of file metadata, search capability, etc. One big thing they were touting was dynamic folders (can't remember the exact wording) wheer basically you could create one of these folders, specify filters or metadata, and have a "folder" that contained all the files that matched that criteria on your drive. From the early descriptions it sounded like you could treat everything as a linked file, though I don't know how they planned on having the delete function work.
Which is odd, because after reading the beginning of the patent this doesn't sound at all like what is being patented.
The patent itself sounds like they are patenting a system of order fulfillment to basically find the cheapest distribution warehouse to ship an item from based on the amount of orders already sent there, amount in stock at that warehouse, cost of shipping from that warehouse and restocking that item, and several other factors. Basically they are building or purchasing an order fulfillment system similar to those used in manufacturing plants to build automated production schedules, except in this case they are likening the shipping of a product to production. Yes, customer expectation is part of the equation and has a financial weight attached to it, but looking through the 50-something initial points, the customer is only one factor among many.
Whoever allowed them to have a patent on this ought to be ashamed. This entire patent is a process definition except it's "for the web" which somehow makes it special and it's "software" to fulfill the outlines process, which somehow makes it patentable. I don't see anything inventive in the process, they just have a different set of manufacturing variables and processes and do it "on the web".
Understand that my answer is going to be mostly from the point of view of a manufacturing business, as that is where I have experience with ERP.
Basically the ERP system is (or has become) the central system for managing everything from reception of an order through fulfillment of the order. Some systems even include warehouse management and truck scheduling. ERP is an expansion of MRP II, attempting to manage the enterprise activities as a whole where MRP II was attempting to manage inventory and manufacturing areas of the business.
In broader terms this means things like: General Finance Sales Order Entry, EDI, Purchasing, etc Accounts Payable Inventory (Possibly just the total amount you have of something, possibly broken down by warehouse, possibly tracking down to the bin/shelf level) HR - Employee management (employees are one of the critical resources to filling an order) Product management (Bills of Material) MRP functionality Product costing Quality control (including things like CAPA systems, document management, etc) Possibly Shop Floor Control - though this is definitely an area that requires massive customization in my mind etc.
However, seeing as these systems are apparently being used in university settings for things like class scheduling, there is either a lot more modules/etc out there to extend ERPs outside of classic business models, or someone has decided to buy and install an $x million solution for purchasing, HR, and inventory and then $xx million worth of modifications to handle things like class enrollment and such.
And of course since we are trying to replace anything from 1/5 to the entire company with one software package, several important items that often get glossed over (scope, requirements gathering, planning, testing) generally make for even more visible and expensive failures. And this includes failures where the software continues to be used despite innate problems because, darn it, we spent $xxx million on this and we are going to use it even if it does lose 1 out of 4 sales orders, or overpay 20% of them time, etc.
Interesting, we're small enough that we don't have a dedicated Systems Admin for our Windows servers, but we only reboot 3 times a year at the most (24/7 operation with very few full-plant outages). And usually those reboots are not to restore normality, but to apply any software patches, software upgrades, etc that have been waiting for enough downtime to be applied. Christmas is going to be fun this year as we will be doing a large number of security updates, adding some new servers, and redoing the oldest switch cabinet in the plant.
Slashdot Mirror
I don't think that's the case. I think the Single Barrel actually refers to the fact that it wasn't transferred to a second barrel :)
For instance, look at the The Balvenie DoubleWood as one counter example of single-malt, multiple barrel.
The screw-top does provide a plastic seal. If by "plastic" you mean foam corks, then no they do not provide an air-tight seal. In fact a lot of R&D effort is currently going oni to better understand the level of oxygen transfer that helps the wine age, as it is already known that no oxygen transfer harms the aging process. While this is good for cheaper wines and may help fruitier wines, your premium wines that are put in a bottle and expected to be aged need this oxygen transfer to reach their potential. The largest synthetic cork manufacturer is leading research and symposiums on controlled oxygen transfer (which makes sense, much easier to control density in a manufacturing process than in a tree growing/skinning process).
Screw-caps are actually the cheapest solution on the market, synthetic and natural corks are priced similarly, depending on the quality of the closure (premium natural/synthetic to less-than-premium synthetics and the corks that are mostly cork shavings).
Is it me or did you just complain about a bunch of things that windows CE does poorly but that the competition doesn't do at all (mixed with a few things that the competition does better)?
Ive worked with Windows CE for a while, as well as a number of other mobile OSs. I agree with most of your list and Windows CE likely annoys me to a much greater level than you as a user. Some of the problems you listed are definitely CE issues, but some are not. .Net 3 and IE6 already built in, as well as a number of the more annoying CE "feature" applications removed. So while some of the blame is definitely on MS, a good portion also needs to rest directly on the vendors AND the telephone providers (you know, the same ones that don't allow you to upload applications over a cable and demand you do a wireless data transfer despite the fact that the device manufacturer specifically built in the capability).
When a vendor decides to put CE on a device they compile a specific version for their device and determine what to include. We are looking at a device with Windows CE 6 that has
I'm left wondering what kind of companies you guys work for that you believe complexity only comes in algorithmic flavor.
I provide comments for the following:
Class level - this is the general idea of the class as a comment so you don't have to grok the entire chunk of code at once
Method level - this is either for doc builders or like the class level, to get a general idea of how something works without reading the next 500 lines
Complexity - Whether it is algorithmic complexity, business rule complexity, whatever - if it is not immediately obvious _WHY_ I am doing something, it gets a comment
So far most of these comments have been along the lines of "I don't comment because I make readable self-documenting code". Great, but when I come back in two years to maintain your code and I am trying to figure out why you did something a certain way - a comment with a little information on your intent or why you programmed your logic in that manner goes a long way
Self documenting names are great, but assuming that you don't also need commenting because of your naming technique is a bad assumption to make. The fact that code changes are done without accompanying comment changes does not invalidate the usefulness of comments, it invalidates the level of work you think your doing.
I would disagree. Planning and Design is every developers responsibility. Whichever piece your responsible for (from the whole thing down to one small chunk), you spend time planning it before jumping in to put code on the screen.
Even if you have smoeone who works full-time just on documentation, you should be providing them with at least notes and good comments, if you don't have a documentation person than don't expect your Mom to come in and do it for you later.
Version Control is iffy, depends on your environment. Some places won't let certain levels of developers touch version control, some places only have one developer and versioning isn't even setup yet. in the second case it should be setup and used, in the first case someone else has the responsibility.
Self-testing is critical in many environmants. Small development groups may not have dedicated test people, frenzied environments may have test people, but part of the testing should include "Does it work the Way I, as the developer, expect it to?". In a frenzied environment you don't often get a chance to go back and fix these things, test early and test often.
By spreading the resources into separate departments you may see some short-term gains from members focusing on their new departments, but in the long term this method is going to cost you. Without a cohesive strategy your going to be leaving each technical person to build their own solutions, follow their own standards (if they have any), and operate against one another when their specific departments do not agree on a solution. Your department specific people will communicate less with one another than with their respective departments, causing a lot of redundancy and friction, especially when several representatives have their hands in the same multi-department system.
I am an IT developer. I attend kaizen events, initiated a long term IT strategy to match the business needs by interviewing each department director combined with the feedback I receive regularly from people who work on the production floor, and I communicate solid plans (and results) to people involved in any systems change from the lowest to the highest levels.
I am an IT developer, yet I led a server migration late last year that involved the ERP system, legacy warehouse system, and multiple support systems that would not only be getting OS upgrades, but also SQL Server upgrades and a complete rename to the new naming structure. Everyone, from the CEO down to the associates running the equipment, knew that the upgrade was taking place, how it would affect their daily lives, and had seen a list of the affected systems in order to provide us any information they felt was missing. We executed the actual migration with two weeks of pre-work and testing and used 2 of our planned 3 day outage (company was closed for Christmas week). We had zero downtime when everyone came back on January 2nd and finance only found two excel docs that misbehaved, a 10 minute fix and no lost time (they wouldn't have been critical until late in the year).
I concentrate on my job and that job is to provide tools or technical opinions to help make the current operations more efficient or reduce the overhead necessary to operate as a company. I think it is my duty to know how the company operates at all levels, rather than assuming that an executive is always able to make a decision that provides benefit, instead of detriment, to the process.
The biggest failures I have seen is non-technical people making technical decisions or assuming that because they once built a computer at home, programmed macros in excel, or led a project with a heavy IT element, they have the knowledge and expertise to not only do my job better than me but to provide technical review on prospective software purchases or installations. These are the people that lead projects or make decisions that force IT to work on non-value added activities or to accelerate timelines into the high-risk territory, simply because the company ends up listening to the barely technical instead of someone that has a solid technical background.
I agree that IT is suffering a problem. That problem is the business listening to the barely technical above, who think that the ability to do one thing has given them the knowledge and experience to override someone that has done that one thing hundreds of times and understands why "making it work" is not the goal. I don't care if you can make a *nix server work at the end of the day. If you couldn't follow a standard process, ensure the documentation has been added to allow the next person that comes along to work on it competently, ensure the backups have been scheduled appropriately, ensure the extra services on the system have been battened down, setup the monitoring system to monitor everything down to the chassis fans, etc then you have hurt the company, not helped. Making it work is the easy part, the hard part is making it work for the long term and ensuring that the longest part of it's lifetime, maintenance, can run as smoothly and efficiently as possible. When the barely technical start making technical decisions the project may get done a l
And I am an IT person with a CS degree that worked as a historian and i/o integrator, industrial software developer, and most recently have been working on a project to integrate equipment w/ layer 4 scheduling data.
Most of the places I have done work for I have seen at least a small number of HMIs that were running on Windows (InTouch, ProcessBook, RsView, etc). I agree that kiosks can be built running off of a read-only image, etc but that takes a great deal of effort, especially for a system that likely cannot be imaged for easy replacement. A better solution would be to install the antivirus and tell it which files need to be ignored. If this continues to cause problems for the system then it is likely you are running more than an HMI on it. Disconnect those serial rocket boards, install some nice serial to ethernet switches, and put your I/O on a server instead of a PC where anyone could walk by and mess with it. Just because you can connect live I/O to a PC does not make it a good idea.
If your HMI is overloading the PC when anti-virus is installed, your doing it wrong.
An even better solution would be to stop using PCs entirely. There are a lot of really good CE-based HMIs out there that are built specifically to run HMI software.
And rather than closing with a broad generalization as you have done, here is a more specific comment from my own experience:
It's that damned subset of engineers that insist only on hardware requirements and install equipment without any regard for how it needs to interact (or in many cases how it will communicate at all) with data systems and other infrastructure, regardless of the consequences. The good engineers take a step back and determine the true needs of the equipment and process, requiring vendors to provide them with solutions for the larger scope, not just something that can be slapped in and called working.
My last gaming rig I went with an Antec P180 and an Enermax Silencer 2 PSU. XP 3400-ish, 2GB, 7800GTX OC (getting a bit dated now). It's not silent but you can't even hear it next to the $150 linux box next to it. If it's the only thing running there is a very quiet sound of air moving in the background. I found the case and the PSU made the biggest sound difference, everything else in the box can either be turned down (antec 3-speed fans) or replaced cheaply (quieter 40mm fan $8, quieter CPU fan $12). The other main noise point I used to have was the HDD, but most newer drives use something like fluid dynamic bearings and the P180 has silicone pads around just about everything to kill vibrations.
I'm not sure what kind of business your outlining there, but I know in the manufacturing world you would be asking for trouble. If nothing else you would need a pretty large pipe to push all the machine control data to the internet at sub-second rates, so they could be operated on by a internet-based software logic engine that looks up information from the internet-based formula management database, which then writes back PLC-specific data to the plant PLC and HMI to tell the operator they cannot use that part in their current order...
I agree that there are a number of business office tasks that could be easily ported to other systems if made agnostic and many of those could possibly moved to an ASP, but I don't see the bandwidth or applications to move manufacturing floors to an ASP, much less convert what is primarily a Windows environment (ie, the majority of manufacturing software, the rest is VMS, Solaris, and others that are slowly fading out) to run on a secondary operating system.
And from what I understand from a friend that worked at MySpace not too long ago, the server architecture is non-existent. Basically tons of servers pressed into service as and when needed with no plans, documentation, etc. One story was how a server had failed that was believed to be providing critical data replication services to and from other servers. The job was to determine which of the other hundreds of servers were expecting data from this server, which thought they were supplying data to this server, and what else might have been on it. Then to re-create it.
If thats their systems administration and design I'd hate to see how painful the help desk side is...
Personally I would forget most of the encryption and delivery schemes already mentioned above. None of them account for the security at the end-users site. Even NDA's do not strengthen the end-users security if it has holes (or is non-existent).
Using either the data export or a copy of the database you are exporting, create a series of scripts to junk the data. For the SSN field have it replace all of the digits in the SSN with randomized numbers. Swap values between each recor and a randomly chosen record for the first name and last name fields (independantly, so that no one record has the original first and last name together anymore). Do the same random number digit replace on all street fields. Do the random record swap on all city and state fields. Continue with whatever else you have.
This may take longer than just faking up some data, but it ensures they have real values in data fields for testing, the format of the data is exactly what your real data is, and it should be absolutely useless in the event of a security breach between the two sites or at their site.
Now send burn it to a disc and set it via registered mail to ensure it gets there.
RoadRunner started doing this a few months ago in my area. Luckily they made an opt-out option very accessible as part of the search page. I'm against the whole idea of replacing non-existent domains with ISP generated content, but if they're going to do it then having a painless opt-out option should be mandatory.
It seems as if your decided on CS for a degree. While many people have posted on the additional experiences and opportunities that you could have by going to a school that will likely focus more heavily on required classes from outside your chosen degree path, I have yet to see any posts on another important factor: How broad is their CS program?
I went to a college that had a smaller CS program, but it was decently broad in nature. By the time I got to the 400-level classes there were 15 or less people in each class, but the classes also represented a great number of sub-fields in CS; from advanced classes in AI, Distributed Computing, and Signal Processing to a number of more esoteric courses they were trying out in web and 3D modeling. Not to mention the ability to pick up business classes or additional math or science classes (or even Liberal Arts courses) that could allow you to pick up a minor or further explore another interest.
If your primary goal is a CS degree, I agree that it rarely matters to an interviewer where you received that degree (though it does matter on occasion). However, the breadth of courses available from the institution and the number of classes they will _allow_ you to take from your major (as opposed to required credits from other branches and required elective credits from other branches) are going to have an impact on the level of knowledge you attain and the number of sub-fields you will get to explore. Additionally, you should look into how much the school supports internships. One of the things that helped me best during my college education was the fact that I was working for pay on real projects, which then gave me a different perspective on the course material.
Also, if you are considering a highly recommended liberal arts school and a highly recommended tech school, why not look at one or two state colleges that have good CS departments? The price range (even out of state) may be in the same range you are looking at for that liberal arts college, the fact that it is a state school will likely have brought in students for a wide variety of degrees, but (if you use CS program quality as criteria) there will also be a greater breadth of CS classes available, allowing you to learn about multiple sub-fields to better determine where you would like to go in CS.
In cases where buying and selling of power is happening at the plant level, it is not going to be the equipment operator that is buying and selling power. And the person selling power does not need access to SCADA systems, thats what the telephone is for and why they have operators at plants to run the equipment. if somewhere there is a plant that is small enough that one person is both buying and selling power AND running the equipment, I'm betting they barely have an internet connection, much less the money to keep up on annual maintenance for the equipment, etc.
In the power plants I have worked in (mostly gas turbine, only one nuclear), there was not any type of internet access from PC's on the controls network. For the most part these systems only ran some form of HMI software (WW, RS, WESstation, whatever) and occasionally something like MS Word or Excel for shift pass-down notes. Sure they had a browser (on the Windows systems) but it wouldn't get them anywhere because there was only one system that had any level of access to both the business intranet and the controls systems. This system (data historian) could only receive communications from the controls side (which had interface software that knew how to contact the historian) and communicates in a proprietary protocol.
Now, as far as the corporate office is concerned, pencil and paper are good enough to keep track of which plants are running which generators, which plants have which generators down for minors or majors, and which plants have generators idling (running with no load at very low levels, not on the grid - cheaper to idle them in most cases then to shut them down). However, in the case of at least one company I worked for, their historian had an interface that pushed data back to a corporate historian, then some reports and so on would run at corporate that drew data from the corporate historian and reported machine statuses, load level, etc up to the last few seconds. This is again using the same proprietary protocol (or heck, maybe a different one).
I don't know what power company this article is about, only that I didn't work there and didn't do any type of integration for them. Whoever setup their infrastructure hopefully learned a lesson and will do it right next time.
Ok, what?
First, I'm not sure if your talking ASP or ASP.Net, but either way the vast majority of your comment can be shortened to:
There are lots of PHP packages out there. People think they are safe because they are not MS. PHP packages should be re-written in ASP. PHP breaks due to updates but ASP updates better, therefore ASP is a better choice. PHP isn't inherently insecure, it's the packages.
Your entire statement boils down to this logic:
1) There are a lot of insecure Packages in PHP
3) It's not an insecurity in PHP, it's an insecurity in the packages
2) ASP updates better than PHP
Your comparing apples (ASP) to oranges (PHP Packages). I have no experience how well or poorly the security of packages in PHP perform against the security of packages in ASP.Net, we would have to pick a large pool of them to find out. And just because Windows Updates makes updates available for ASP.Net does not mean that people actually are that willing to reboot their web farms for every update that appears. Your saying the problem is bad coding and that ASP solves it, I would beg to differ.
And here is my anecdotal comment:
I have answered thousands of ASP questions (ASP used to be my primary web 'language') as well as written/re-written many sites and over time I have seen a lot of site examples and snippets that would leave a page wide open or in a position to break on regular occasions (or just plain didn't work). On the other hand I have worked with several PHP packages that were solidly put together and worked against a range of PHP versions. PHP must be better because I haven't personally seen anywhere near as many errors in coding as I have in ASP. None of the first several thousand ASP posts would work at all against the next version of the language (ASP 3 => ASP.Net) and needed to be rewritten from scratch, but most or all of the packages I used with PHP 4 worked just fine with PHP 5.
Well, if your gaming on a dell, then I can believe the low price and disbelief. My last price list looked more like:
Case: $125
PSU: $125
Mobo: $125
CPU: don't recall, I think $300-ish
Ram: $100-$200
HDD: $100
GPU: $500
Mouse: $50 (x2, I've worn at least one out since I built this system, maybe two)
22" monitor: $300 (recent purchase, 2ms LG)
Granted I plan on reusing the case and PSU on the next rev of this system, which is why I went with solid ones, and the only reason I bought a $500 graphics card was because I never had before (I usually buy the bast card from 9 months ago, that time I bought the best card). This investment gave me a box that stayed near enough to the higher end for a while and still, two years later, plays everything I want very well. I'll probably be looking at an upgrade later this year, at which point the Mobo, graphics, and RAM will migrate to either my wife's box or the PVR. Sorry, I just couldn't see getting the same performance from a Dell.
Master pages were actually created in response to the fact that doing includes or "components" (to keep your header and footer logic/presentation centralized in one file) was somewhat painful. It's once again hit the magic MS bar of implementing an idea so far, but no farther. If you look behind the scenes at a number of PHP packages (phpBB3 comes to mind) you will see a full (real) templating system built-in that goes beyond the basic "surround the content with some stuff" that master pages gives you. At the other end of the spectrum you have simple file includes for headers and footers that give you exactly the same capabilities as Master Pages.
If anything, Master Pages to me were another example of ASP.Net going the wrong way. For all of the arguments about separation of logic and presentation, I don't thin the ASP.Net architecture quite gets how the web works and what layer is supposed to be separated. While it is possible to have good seperation between a data abstraction layer, logic, and presentation, what you often get is a mish-mash of the three as ASP.Net attempts to make components available to do the work for you. And the further you wander towards dynamic content and good seperation, the more painful it becomes. Just look at the validator controls and the fact that they have to do extra work to figure out what client0-side control will be called when they are rendered and renamed. ASP.Net starts with the presentation aspect and everything else derives from that. Languages like PHP or ASP 3 may not force you to use data abstraction or other good methods, but it's the same as saying your starting a race at the starting line (PHP) or starting the race 5 miles back and facing the wrong direction (ASP.Net) but man you have some nice shoes to run in.
At least you threw in the 'competitors' comment this time, so I'll have to extend my normal argument.
Show me the Open Source industrial data historian and HMI/QA suite. The tool suite must have:
HMI software
a logic engine to work with real-time process data using programmable objects
additional components or packages to track downtime, performance, utilization/efficiency, order management, recipe management, traceability
SPC and SQC tools
Be accessible for import into some basic tools like spreadsheet tools
Be accessible from a database server/reporting server
Have drivers for: Start With This list and then finish this one
Whoops, we need a reporting server too, so add that to the list also.
Could I write all of this software? Yep, with some help from other software types and some EE's and licenses from just about every company listed on the above websites to allow me to write drivers that talk their proprietary languages (which I doubt they would allow to be Open Sourced). However the cost would end up being much greater, especially in this vertical market, The 'competitors' you mention would need to each be paying for developers and EEs for the rest of their lives in order to keep their software tools up to market standards, continue to port them to new systems as they come out, etc. In the far off future it might be worth it, provided licensing fees to AB, Siemens, etc don't hurt too badly. The real question is how many manufacturing companies (not even real competitors) band together to bring the price down and how do you justify double or tripling their licensing costs for the at least the first 3-5 years (they're paying to continue to use what they have and for development of new software) just to barely do less than break even from then out? Assuming you get a good following of consultants to do training and installs for your product, how do you provide them with support on top of the development?
I could continue, but the point is that every time I see someone make a generalized comment about companies banding together to replace their software with Open Source, I notice that the entire manufacturing segment is left out of the equation. I'm not saying it would be impossible or that there aren't some tools out there already, only that Open Source isn't even close to being on the radar in this area right now at the level of paid-for alternatives, and would require companies to throw significant money away in order to catch up quickly while still leaving them dealing with the equivalent of thousands of broadcom drivers.
That depends on what you mean by "utilities". If your talking about corporate offices and so on, then yes, i'm sure they are hooked up to the net the same way most large businesses are. If you mean the individual plants, well, thats different.
The last power company I worked for in the the US (Southeastern US) was most definitely not setup this way. While it was possible to remotely connect into various plants, the deepest you could go was to connect to the Data Historian that had limited connectivity over to the controls network to receive data from the equipment for storage. Not that there was direct access to the plant, first you had to VPN into the corporate servers then from there you had to know exactly what you were looking for (since the handy directory of historian server names was under pass and lock elsewhere) to connect to the server at one of the plants. The plants were setup with the controls systems completely separate from the intranet at the plant (except for the one connection to the historian). PCs, on the other hand, were setup on the corporate business VLAN and completely separate from the controls systems, so no other variables are introduced.
In order to do anything to affect the controls you would have to take over the data historian, which itself had very limited connectivity (basically enough to pass data on to the corporate historian and send weekly data backups to a corporate server). Then you would have to reverse engineer the proprietary communications protocol between the server and each of the software interfaces on the controls side. At that point, provided you found some method of causing a buffer overflow or some other type of similar vulnerability, you would have access to a software interface that had a read only connection to either PLCs or another intermediary piece of software. Provided you could then perform some piece of magic (not counting the one involved in decoding the communications protocol and finding a hole in it), you would have the ability to read any tag value from the equipment that interface was connected to...err, and you still wouldn't be able to control anything. And those interfaces are able to handle subsecond poll rates on thousands of values, so taking them out by trying to DOS them from the Historian would be difficult and, since they aren't controlling anything, fairly useless.
I'm not sure the idea of splitting the IT responsibilities into other departments is insane (hold with me a moment). Consider the current situation of an IT department that is a separate department, usually with their own goals, budget, etc. This department is notable for not always getting new PCs as fast as they are wanted, for not implementing software changes immediately when requested, and for demanding additional money when deploying technologies like video conferencing so they can upgrade the internet connection or some other foolishness. Oh, and they always act like they are busy, but we all know the systems hardly have problems.
Unfortunately the suggested solution, of splitting IT into the surrounding departments, is going to look like a good idea to many director level people. It will (in their minds) ensure immediate service for new equipment, allow a higher level of control over the purchase of items they think are unrelated, and allow them to have changes made to software at a higher level of priority. To the outside manager or director, they generally only see what we are not supplying, not what we are. If we are good at our jobs, but have poor systems, they don't generally realize just how bad things are because we are keeping the system limping along. A lot of our expenditures are due to reasons they just don't understand. If we buy a 48 port managed switch with fibre but were rolled under one of these departments, it could very easily turn into a refurbed 48 port hub off ebay, since they both have lots of connections and thats all you really need.
What about change control? They don't see it. Time for testing? That will get reduced further. Developing in test environments? But those are good machines, they should be used for something important. Oh, and why do you need fancy development tools? Joe down the way made an application to do that in 45 minutes using MS Access, but it takes days in this fancy technology, we'll just use MS Access instead.
The whole idea of splitting IT up into several departments is like a startup company (non-tech) in reverse. Money will go to IT-related resources last, it will be in no one's interest to spend the time, resources, or money to ensure there is a strong infrastructure capable of growth, in house software development will be on-the-fly and likely based on technologies like MS Access. On top of that, larger initiatives like data warehousing, global data management will be left to whoever wants to pay for the whiz-bang consultant to come in and do it their way. Backups, email, directory services, all of this will end up on someone's plate who will forever be trying to drop it off on someone else.
I realize that the author of that article was likely thinking that IT resources would not need to deal with most of these things in the future, and for that I can assume he has not worked in an IT environment in quite a while. While technologies are available to streamline our jobs and allow us to grow the department(s) more slowly that in the past, splitting the department so that no one has these responsibilities is going to have one positive thing going for it: The consultants that come in to clean up the mess after the takeover are going to be set for a good long time.
Half-right and half-wrong.
While NTFS would have still been used behind the scenes, you the user would have been interacting with WinFS as your filesystem. It was intended for every file and allowed for a greater level of file metadata, search capability, etc. One big thing they were touting was dynamic folders (can't remember the exact wording) wheer basically you could create one of these folders, specify filters or metadata, and have a "folder" that contained all the files that matched that criteria on your drive. From the early descriptions it sounded like you could treat everything as a linked file, though I don't know how they planned on having the delete function work.
Which is odd, because after reading the beginning of the patent this doesn't sound at all like what is being patented.
The patent itself sounds like they are patenting a system of order fulfillment to basically find the cheapest distribution warehouse to ship an item from based on the amount of orders already sent there, amount in stock at that warehouse, cost of shipping from that warehouse and restocking that item, and several other factors. Basically they are building or purchasing an order fulfillment system similar to those used in manufacturing plants to build automated production schedules, except in this case they are likening the shipping of a product to production. Yes, customer expectation is part of the equation and has a financial weight attached to it, but looking through the 50-something initial points, the customer is only one factor among many.
Whoever allowed them to have a patent on this ought to be ashamed. This entire patent is a process definition except it's "for the web" which somehow makes it special and it's "software" to fulfill the outlines process, which somehow makes it patentable. I don't see anything inventive in the process, they just have a different set of manufacturing variables and processes and do it "on the web".
Understand that my answer is going to be mostly from the point of view of a manufacturing business, as that is where I have experience with ERP.
Basically the ERP system is (or has become) the central system for managing everything from reception of an order through fulfillment of the order. Some systems even include warehouse management and truck scheduling. ERP is an expansion of MRP II, attempting to manage the enterprise activities as a whole where MRP II was attempting to manage inventory and manufacturing areas of the business.
In broader terms this means things like:
General Finance
Sales Order Entry, EDI, Purchasing, etc
Accounts Payable
Inventory (Possibly just the total amount you have of something, possibly broken down by warehouse, possibly tracking down to the bin/shelf level)
HR - Employee management (employees are one of the critical resources to filling an order)
Product management (Bills of Material)
MRP functionality
Product costing
Quality control (including things like CAPA systems, document management, etc)
Possibly Shop Floor Control - though this is definitely an area that requires massive customization in my mind
etc.
However, seeing as these systems are apparently being used in university settings for things like class scheduling, there is either a lot more modules/etc out there to extend ERPs outside of classic business models, or someone has decided to buy and install an $x million solution for purchasing, HR, and inventory and then $xx million worth of modifications to handle things like class enrollment and such.
And of course since we are trying to replace anything from 1/5 to the entire company with one software package, several important items that often get glossed over (scope, requirements gathering, planning, testing) generally make for even more visible and expensive failures. And this includes failures where the software continues to be used despite innate problems because, darn it, we spent $xxx million on this and we are going to use it even if it does lose 1 out of 4 sales orders, or overpay 20% of them time, etc.
Interesting, we're small enough that we don't have a dedicated Systems Admin for our Windows servers, but we only reboot 3 times a year at the most (24/7 operation with very few full-plant outages). And usually those reboots are not to restore normality, but to apply any software patches, software upgrades, etc that have been waiting for enough downtime to be applied. Christmas is going to be fun this year as we will be doing a large number of security updates, adding some new servers, and redoing the oldest switch cabinet in the plant.