In general it is useless, but there may be some odd side perks to consider.
In any security scenario such as this, step number one is always to develop your threat model. What are they trying to defend against? Script kiddies? Three letter agencies? Foreign nationals who will stop at nothing to hack your servers? Disgruntled employees? How long will you need to defend against them? Are you worried about a offhanded "You pissed me off, so I'm going to hack you" or a "I am so infuriated by your company that I will spend months planning and executing the perfect attack?"
I usually don't recommend this, but in this particular case, we may be able to think of a reverse threat model. We can look at the existing security (user/pass+access) vs your desired security (user/pass) and determine what threat models might distinguish between the two.
In both cases, an attacker must compromise someone else's account, because their own account was disabled or removed. Getting the username is always easy, so the difference is how hard is it to get someone's password plus the company wide access code vs. just getting the password?
The answer to this, as all good security questions is "it depends." How good are your employees at picking passwords? If you regularly find that people are using their own username or "password1" or their dog's name as a password, a company wide access code may be the only thing between you and a disgruntled employee hacking you! (of course, it also implies you have many other security holes). On the other hand, if acquiring someone's password is reasonably hard, the access code won't buy you anything. An access code would be given out far more freely than a password would, so if they can get the password, they can get the code.
So the only threat models which can distinguish between your solution and theirs are threat models which are worried about an ex-employee who can get ahold of another employees password (something we are trained not to give up in this day and age) but for some reason cannot get ahold of an access code that is explicitly shared between everyone. That's a pretty degenerate case.
Bruce Schneier loves to say "Security is always in a balance with usability." In this case, the usability of a shared password is nightmarishly bad. The security gained is quite minimal, if anything. The access code should be thought of as a bad security trade and dismantled.
There are two exceptions I can think of. One is that a company access code may be developed as a token to keep individuals honest. Consider the police badge. Itself, it's just a hunk of metal in the shape of a shield. However, it is a symbol which reminds people (civilian and police alike) that they are accepting a higher responsibility.
The other example is that I have seen labs where, for security reasons, everyone must badge in with their own PIN, but the badge reader is not trusted on its own. In addition to this badge reader and pin, they have a combination lock which is trusted. Every person working in the lab knows the code to the combination lock, so that they can open the lab if they are first in the morning. Once the combo is opened, and there is at least 1 authorized person in there, everyone is allowed to just use their badge/PIN for convenience. At night, the combination lock is locked. If anyone is revoked from the list, they must change the combination, because it was the part of the system that is "trusted."